Hi, Wouldn't it suffice to add a field for the hash value and a flag that indicates its validity to zval instead of appending zend_literal everywhere?
Moriyoshi On Wed, Mar 24, 2010 at 11:12 PM, Zeev Suraski <z...@zend.com> 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.wikipedia.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
