There is some very cool serialization alternatives out there, the coolest is igbinary, it much faster an save space…
It would be cool if there will be an option to switch serialization function…
maybe in main app config… serialize or json_encode, or igbinary etc.
Don’t sure if it will save much time, but maybe at least space
Fore reference: I think this is referring to this project.
Well, it looks promising. The only problem I see so far is that igbinary is producing binary output. That’s a bit hard to debug and some components (CDbHttpSession and CDbCache) will need adjustment to cope with the binary format. Anyway: Thanks for the hint.
I would stick to serialize or json… maybe you could benchmark them (both serialize/unserialize json_encode/json_decode and use the faster one).
I did a little benchmark, I tested var_export with return cache, serialization, json_encode, igbinary…
igbinary kick *ss 
he is about twice faster than all the variations, and he saves about 50% space. if serialization result take 80, igbinary would produce 40…
I hope I dont lay to you… it was half year ago… now I use only igbinary…
I did a little tutorial for caching main.php
there you have the example and reference to github , as Sourcerer posted
http://www.yiiframework.com/wiki/234/caching-the-config-main-php/
I actually managed to find a very recent benchmark. At the same time I’ve been experimenting a bit with compressed sessions, resulting in a more general compression approach (it’s not ready for a patch, yet). In my experience, the output of PHP’s native serialize() compresses really well. Serialized data passed through gzip/lzf tends to be even smaller than igbinary’s output. However, it will add some CPU overhead. I’ll have to run some benchmarks but my guess is: igbinary is the faster approach while gzip(serialize()) leads to smaller sessions.
I’d would use a human readable approach, not some non-standard binary approach.
Oh, here’s that thread
Just a small addition: Set igbinary.compact_strings to Off for a greater speed benefit. This will result into larger serialization strings (don’t worry, they’re still smaller than PHP’s serialize() output). But I’ve found that the speed advantage is lost in a lot of circumstances.
I think the point is to support different serializer to drop in , adapt in, not on which is better and faster.