Re: Move to Fast ZPP?

From: Date: Fri, 26 Jun 2015 21:45:30 +0000
Subject: Re: Move to Fast ZPP?
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-86918@lists.php.net to get a copy of this message
Hi Levi, ----- Original Message ----- From: "Levi Morrison" Sent: Wednesday, June 24, 2015
On Wed, Jun 24, 2015 at 3:21 AM, 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?
Honestly it has a nicer API and I prefer to use it over traditional ZPP in every case.
I think I agree, but thought it was a moot point. :-/ But now I've created a version that uses the same syntax and improves performance, but without the code size drawback of the "inlined FAST_ZPP." So perhaps we WILL be able to use it in every case, depending what Dmitry/others think when I share it shortly. :^) - Matt

« previous php.internals (#86918) next »