Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86859
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <051CB45EE4B24C7C88C3EABC7E8EE0A2@pc1>
References: <CAGa2bXY1hKW3qX3jBwKge7RDihS6TjxAW3p+-kKRiW4OmePLSQ@mail.gmail.com>
	<CAH-PCH6YtrM8B1DBWXL7+5mfgUROKKwqFd2VDL+FZtUEfRpREw@mail.gmail.com>
	<CA+9eiLsrG5TiFEv=2NQPTQxcvMZD9gd0bQLsn7xMQU7HU-oaYQ@mail.gmail.com>
	<051CB45EE4B24C7C88C3EABC7E8EE0A2@pc1>
Date: Thu, 25 Jun 2015 09:42:01 +0300
Message-ID: <CA+9eiLv1zQtxyWyOU-ORRvmsuFyUFtys2jHLGkgmMJUgqEo0qQ@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113321eeb897b4051951eb76
Subject: Re: [PHP-DEV] Move to Fast ZPP?
From: dmitry@zend.com (Dmitry Stogov)

--001a113321eeb897b4051951eb76
Content-Type: text/plain; charset=UTF-8

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
>

--001a113321eeb897b4051951eb76--