On Sat, Jun 27, 2015 at 12:36 AM, Matt Wilmas <php_li...@realplain.com> wrote:
> 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. > Send you implementation as soon as it's ready. I'll test it. Thanks. Dmitry. > > Thanks. Dmitry. >> > > - Matt >
