It's been a concept stuck in my mind since I first looked into ZE2.1 and
saw what compiled variables were, and a recent blog post
(http://php100.wordpress.com/2006/11/24/optimizations/) (which got
picked up by planet PHP) got my wheels spinning again. Tonight I
decided to actually sit down and see what benefit could be milked from
such an endeavor and what it's maintenance cost would be.
The attached patch shows what I've tossed together for HEAD and the
benchmark I've run against it do show some appreciable gains...
Based on this code snippet, I saw a consistent gain of aproximately 18%:
for($i = 0; $i < 10000000; $i++) pi();
I chose the pi() function as it (A) would actually favor the unpatched
approach, being quick to hash and strcmp. It also (B) performs minimal
actual work, simply returning a constant value, thus leaving as much of
the execution time to the matter being tested as possible.
Of course, this isn't a "normal use" example, and it doesn't address
dynamic function calls or method calls. I also havn't looked into class
resolution yet, but this is a good spot to begin discussion from.
Thoughts anyone?
-Sara
Looks fairly interesting, I doubt 18% is consistent benefit across
the board, and when unicode overhead is removed is probably less
still. But, it does look like a good optimization to make that would
certainly make PHP faster then before.
Ilia Alshanetsky
Looks fairly interesting, I doubt 18% is consistent benefit across the
board
I doubt it very much too. While I made that test to strip out non-fcall
overhead, I also made it favor the effect being produced by constantly
calling the same function from the same scope. Reality isn't like that.
and when unicode overhead is removed is probably less still.
My numbers were based on unicode.semantics=off just FYI...
it does look like a good optimization to make that would certainly make
PHP faster then before.
I suspect optimized class fetches will help several cases too:
foo::bar();
foo::baz(foo::BLING);
Just not going to bother working on that unless it sounds worth doing to
enough people.
-Sara
Looks fairly interesting, I doubt 18% is consistent benefit across
the boardI doubt it very much too. While I made that test to strip out non-
fcall overhead, I also made it favor the effect being produced by
constantly calling the same function from the same scope. Reality
isn't like that.and when unicode overhead is removed is probably less still.
My numbers were based on unicode.semantics=off just FYI...
That's good, although unicode based PHP does have a number of
additional checks not present in non-unicode version (not-PHP6).
it does look like a good optimization to make that would certainly
make PHP faster then before.
I suspect optimized class fetches will help several cases too:
foo::bar();
foo::baz(foo::BLING);
Only for native classes though.
Ilia Alshanetsky
Hi Sara,
Interesting patch.
We had very similar idea in the past.
BTW it is possible to optimize function calls mach more.
Not only ZEND_DO_FCALL but also ZEND_INIT_FCALL_BY_NAME can be optimized,
and we can reuse the same cache entries for all op_arrays from the same PHP
file.
I'll make a patch and send it to you in fey days.
Thanks. Dmitry.
-----Original Message-----
From: Sara Golemon [mailto:pollita@php.net]
Sent: Monday, December 04, 2006 8:49 AM
To: internals@lists.php.net
Subject: [PHP-DEV] Function call speedup (CV applied to functions)It's been a concept stuck in my mind since I first looked
into ZE2.1 and
saw what compiled variables were, and a recent blog post
(http://php100.wordpress.com/2006/11/24/optimizations/) (which got
picked up by planet PHP) got my wheels spinning again. Tonight I
decided to actually sit down and see what benefit could be
milked from
such an endeavor and what it's maintenance cost would be.The attached patch shows what I've tossed together for HEAD and the
benchmark I've run against it do show some appreciable gains...Based on this code snippet, I saw a consistent gain of
aproximately 18%: for($i = 0; $i < 10000000; $i++)pi();I chose the
pi()function as it (A) would actually favor the
unpatched
approach, being quick to hash and strcmp. It also (B)
performs minimal
actual work, simply returning a constant value, thus leaving
as much of
the execution time to the matter being tested as possible.Of course, this isn't a "normal use" example, and it doesn't address
dynamic function calls or method calls. I also havn't looked
into class
resolution yet, but this is a good spot to begin discussion from.Thoughts anyone?
-Sara