Hi Dmitry, all,
----- Original Message -----
From: "Dmitry Stogov"
Sent: Thursday, June 25, 2015
On Wed, Jun 24, 2015 at 1:35 PM, Matt Wilmas <php_li...@realplain.com>
wrote:
Hi Dmitry, all,
----- Original Message -----
From: "Dmitry Stogov"
Sent: Wednesday, June 24, 2015
We should NOT use it everywhere. It'll lead to code bloat.
Thanks. Dmitry.
[...]
Right, FAST_ZPP makes code larger, inlining stuff in each function, etc.
But I was wondering, is there any more that can be done to optimize the
slowness of the traditional ZPP? I don't recall any changes being made
to
it in the last 12-18 months to speed it up at all...
Is there a particular part that's making it slow? Is it the *string* of
param types? Is it the va_arg's, that doesn't allow the call to be
optimized as well and/or the arg fetching that's slow?
I know there were the syntax issues as well, but would using something
like a single param (array pointer) for param types/values help at all?
Or is it just the internals of ZPP that are inherently slow...? :-/ Or
that's fine but the "mechanism" of getting there is the issue?
The traditional ZPP is actually a et another interpreter that reads
specification string char by char and perform actions.
And interpreters are usually slower.
I think it may be improved, but I don't expect significant overall
improvement because of that.
Now, the cumulative overhead of traditional ZPP on wordpress is ~0.4%.
Even if we make it 2 times faster, we may get just 0.2% overall speed up.
Yeah, I knew how the traditional ZPP worked, just wondered about any certain
"problem area." :-) But it seems it's just the whole thing, so much it's
doing, besides just the "string format interpretation."
First, only fractions of a % old ZPP is using on WordPress now? That
doesn't make sense to me... On fast_zpp wiki page, you said last year it
was taking ~6% of time on Wordpress (before FAST_ZPP, of course). And
changing key/hot functions to FAST_ZPP saved ~2.5% time. So that should
have left a few percent of time used by traditional ZPP.
But everything else has gotten faster since then, so therefore, for an
unchanged old ZPP, its percentage contribution should have gone up? Well,
anyway...
I went ahead and tried implementing my idea (had been awhile since I really
looked at the FAST_ZPP stuff, and didn't realize it was as simple to work
from). :-)
It uses the same syntax as "FAST_ZPP" (if we/others like/prefer that) and a
zend_FAST_parse_parameters() function. Code size should be about same as
before, maybe a few more bytes depending on instructions needed (still
thinking/adjusting).
It seems to have pretty good performance increase! BTW, in quick testing, I
don't see old ZPP using 90% of time even with empty/dummy function. Just
about 50% (with or without ZTS)...
I didn't know how close we could get to the inlined FAST_ZPP, but it seems
the majority of the way there: ~70% in the simple case. (To be clear, 3x
faster than old.) This was on Windows XP with ancient VC9.
I don't have a patch ready for you to look at yet, since I didn't finish
changing the macros, etc.
It would be awesome if this could start being used throughout the codebase,
and not just functions with preferential treatment. :-P Maybe you'd even
switch back from the inlined version in some places, if smaller code would
be better.
Thanks. Dmitry.
- Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
