Hi Rasmus,
Rasmus Lerdorf wrote:
On 03/24/2010 07:12 AM, 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.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!
The changes to ext/standard/array.c in that patch don't seem to have
anything to do with the rest of the patch. You should probably separate
that and just commit that part to trunk now.
You are wrong. The modifications in array.c prevent in-place string
modification, because it can be an interned string or even an interned
string from opcode cache shared across several PHP processes.
As far as I can tell the only pecl extensions broken by this patch are:
phk, apc, bcompiler, and automap. Which isn't too bad. But yes, I
could definitely use some help in figuring out how to add support for
this in pecl/apc.
I think the support for literal tables is clear and can be implemented
without problems. APC support for interned strings would be a bit tricky
so I'm going to describe the idea (or even provide a patch) in few days.
Thanks. Dmitry.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
