Re: Move to Fast ZPP?
| From: | Matt Wilmas | 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: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. :^) - MattOn Wed, Jun 24, 2015 at 3:42 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:Honestly it has a nicer API and I prefer to use it over traditional ZPP in every case.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 +0400it 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?Fast parameter parsing APIThis 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