Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77534
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
Message-ID: <54217C2D.1070700@gmail.com>
Date: Tue, 23 Sep 2014 14:57:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAPRqa+GgN6n9nmEUdaP1VxxFddQRwE1QDbxXqT082v3Qy8DzdQ@mail.gmail.com>
In-Reply-To: <CAPRqa+GgN6n9nmEUdaP1VxxFddQRwE1QDbxXqT082v3Qy8DzdQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Improve PHP 7 serialization
From: rowan.collins@gmail.com (Rowan Collins)

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]