Re: Move to Fast ZPP?
| From: | Dmitry Stogov | Date: | Thu, 25 Jun 2015 06:42:01 +0000 |
| Subject: | Re: Move to Fast ZPP? | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-86859@lists.php.net to get a copy of this message | ||
On Wed, Jun 24, 2015 at 1:35 PM, Matt Wilmas <php_lists@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.
>
> On Wed, Jun 24, 2015 at 12:21 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
> On Wed, Jun 24, 2015 at 3:42 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>> > Hi all,
>> >
>> > I'm wondering the state of Fast ZPP.
>> > https://wiki.php.net/rfc/fast_zpp
>> >
>> > Last year's Dmirty's commit message say, it should
>> > only applied to most used functions due to the state of
>> > Fast ZPP.
>> >
>> > commit 27f38798a1963de1c60aae4ef8a3675138255574
>> > Author: Dmitry Stogov <dmitry@zend.com>
>> > Date: Fri Jul 11 16:32:20 2014 +0400
>> >
>> > Fast parameter parsing API
>> >
>> > This API is experimental. It may be changed or removed.
>> > It should be used only for really often used functions.
>> > (Keep the original parsing code and wrap usage with #ifndef >
>> FAST_ZPP)
>> >
>> >
>> > Are we supposed to convert anything to Fast ZPP now?
>> > What about the #ifndef FAST_ZPP? Is this required now?
>> >
>> > BTW, if we are supposed to use only Fast ZPP,
>> >
>> > https://github.com/php/php-src/blob/master/README.PARAMETER_PARSING_API
>> > should be updated.
>> >
>> > Regards,
>> >
>> > --
>> > Yasuo Ohgaki
>> > yohgaki@ohgaki.net
>> >
>>
>> it was meant as a performance optimization for the most heavy/hot
>> codepaths.
>> What gave you the idea that the situation changed and we should use it
>> everywhere?
>>
>
> 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.
Thanks. Dmitry.
>
>
> Thanks,
> Matt
>