Re: Improve PHP 7 serialization
| From: | Rowan Collins | Date: | Tue, 23 Sep 2014 13:57:01 +0000 |
| Subject: | Re: Improve PHP 7 serialization | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77534@lists.php.net to get a copy of this message | ||
Park Framework wrote (on 23/09/2014):
PHP serialization is slowest in PHP Session, clients NoSQL, ... I would like to have in PHP 7, a new serialization algorithm or custom handler to serialize. My opinion is that the best choice is to use msgpack, it is +110% faster -30% data size HHVM discussed this issue, but all boils down to backward compatibility with PHP https://github.com/facebook/hhvm/issues/2654 What do you think about this, maybe it's time to change the old algorithm serialization, on something better?Apart from the BC implications, using a binary serialization by default might cause issues with anyone who is storing or passing the serialized data somewhere which is not binary-safe. Admittedly, any object with private properties generates a serialized form with null bytes, but many values will consist entirely of ASCII characters, and some code may rely on this being the case. The format is also widely known, and has been implemented in other languages for compatibility (although it is **not** suitable for untrusted data exchange, as Anthony Ferrara tweeted a few months ago: https://twitter.com/ircmaxell/status/452182852562862080) We already have pluggable serializers for sessions (needed because the serialization happens implicitly in the session handling code), and can add as many functions for types of serialization as seem sensible, so I'm not sure what the benefit of changing serialize()/unserialize() themselves is. Changing the default *session* serialization might be worth considering, though, along with bundling something like igbinary or msgpack. Oh, and a non-batshit version of session_decode() for manually invoking session (un)serialization handlers :P -- Rowan Collins [IMSoP]