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. > > On Wed, Jun 24, 2015 at 12:21 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: > > On Wed, Jun 24, 2015 at 3:42 AM, Yasuo Ohgaki <yohg...@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 <dmi...@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 >> > yohg...@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 >
