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