Re: [RFC] Performance improvements

Hi Jared, Jared Williams wrote:

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

Not in this patch.

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?

Probably it can. However, I've never looked into it, so I can't be sure. Thanks. Dmitry.

-Jared

-----Original Message----- From: Dmitry Stogov [mailto:dmitry@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