Hi

        Wondering if there is any plans to for new serialization
method?

        One of the things that igbinary does is store strings only
once, and now that the engine supports string interning natively,
seems that serialization and deserialization could benefit.

        Though I guess igbinary could be patched to take advantage of
string interning?

-Jared

> -----Original Message-----
> From: Dmitry Stogov [mailto:dmi...@zend.com] 
> Sent: 13 April 2010 14:53
> To: internals@lists.php.net
> Subject: [PHP-DEV] [RFC] Performance improvements
> 
> Hi,
> 
> I've published all the patches, their description and 
> performance evaluation at 
> http://wiki.php.net/rfc/performanceimprovements
> 
> In two words the patches give 0-20% improvement even on 
> real-life applications.
> 
> I'm going to commit them into trunk in a week in case of no 
> objections.
> 
> Of course, they are binary incompatible. Some extensions 
> (especially VM depended e.g. APC, xdebug, etc) will have to 
> be modified to support the changes.
> 
> Thanks. Dmitry.
> 
> Zeev Suraski wrote:
> > Hi,
> > 
> > Over the last few weeks we've been working on several ideas 
> we had for 
> > performance enhancements. We've managed to make some good 
> progress.  
> > Our initial tests show roughly 10% speed improvement on real world

> > apps.  On pure OO code we're seeing as much as 25% improvement (!)
> > 
> > While this still is a work in progress (and not production quality

> > code
> > yet) we want to get feedback sooner rather than later. The diff 
> > (available at http://bit.ly/aDPTmv) applies cleanly to 
> trunk.  We'd be 
> > happy for people to try it out and send comments.
> > 
> > What does it contain?
> > 
> > 1) Constant operands have been moved from being embedded within
the 
> > opcodes into a separate literal table. In additional to the zval
it 
> > contains pre-calculated hash values for string literals. As 
> result PHP 
> > uses less memory and doesn't have to recalculate hash values for 
> > constants at run-time.
> > 
> > 2) Lazy HashTable buckets allocation - we now only allocate the 
> > buckets array when we actually insert data into the hash 
> for the first time.
> > This saves both memory and time as many hash tables do not have
any 
> > data in them.
> > 
> > 3) Interned strings (see
> > 
> <http://en.wikipedia.org/wiki/String_interning>http://en.wikip
edia.org/wiki/String_interning). 
> > 
> > Most strings known at compile-time are allocated in a 
> single copy with 
> > some additional information (pre-calculated hash value, 
> etc.).  We try 
> > to make most incarnations of a given string point to that 
> same single 
> > version, allowing us to save memory, but more importantly - run 
> > comparisons by comparing pointers instead of comparing strings and

> > avoid redundant hash value calculations.
> > 
> > A couple of notes:
> > a.  Not all of the strings are interned - which means that if a 
> > pointer comparison fails, we still go through a string comparison;

> > But if it succeeds - it's good enough.
> > b.  We'd need to add support for this in the bytecode 
> caches. We'd be 
> > happy to work with the various bytecode cache teams to guide how
to 
> > implement support so that you do not have to intern on each
request.
> > 
> > To get a better feel for what interning actually does, consider
the 
> > following examples:
> > 
> > // Lookup for $arr will not calculate a hash value, and will only 
> > require a pointer comparison in most cases // Lookup for 
> "foo" in $arr 
> > will not calculate a hash value, and will only require a pointer 
> > comparison // The string "foo" will not have to be 
> allocated as a key 
> > in the Bucket // "blah" when assigned doesn't have to be
duplicated 
> > $arr["foo"] = "blah";
> > 
> > $a = "b";
> > if ($a == "b") { // pointer comparison only
> >   ...
> > }
> > 
> > Comments welcome!
> > 
> > Zeev
> > 
> > Patch available at: http://bit.ly/aDPTmv
> > 
> > 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To 
> unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to