Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86918 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78478 invoked from network); 26 Jun 2015 21:45:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jun 2015 21:45:34 -0000 Authentication-Results: pb1.pair.com header.from=php_lists@realplain.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php_lists@realplain.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain realplain.com from 216.33.127.80 cause and error) X-PHP-List-Original-Sender: php_lists@realplain.com X-Host-Fingerprint: 216.33.127.80 mta11.charter.net Solaris 10 1203 Received: from [216.33.127.80] ([216.33.127.80:51526] helo=mta11.charter.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8F/70-10002-DF7CD855 for ; Fri, 26 Jun 2015 17:45:33 -0400 Received: from imp09 ([10.20.200.9]) by mta11.charter.net (InterMail vM.8.01.05.09 201-2260-151-124-20120717) with ESMTP id <20150626214530.TPNM5815.mta11.charter.net@imp09>; Fri, 26 Jun 2015 17:45:30 -0400 Received: from mtaout004.msg.strl.va.charter.net ([68.114.190.29]) by imp09 with smtp.charter.net id l9lW1q0050eWGlw059lWij; Fri, 26 Jun 2015 17:45:30 -0400 Received: from impout002 ([68.114.189.17]) by mtaout004.msg.strl.va.charter.net (InterMail vM.9.00.018.00 201-2473-151) with ESMTP id <20150626214530.JBPD18393.mtaout004.msg.strl.va.charter.net@impout002>; Fri, 26 Jun 2015 16:45:30 -0500 Received: from pc1 ([96.35.251.86]) by impout002 with charter.net id l9lW1q0091sc0so019lWHd; Fri, 26 Jun 2015 16:45:30 -0500 X-Authority-Analysis: v=2.1 cv=Lrgcyxtc c=1 sm=1 tr=0 a=Is5gsZaFXO8aPum+t7Tz+g==:117 a=Is5gsZaFXO8aPum+t7Tz+g==:17 a=hOpmn2quAAAA:8 a=t0KHGDoOaRkA:10 a=BCPeO_TGAAAA:8 a=N659UExz7-8A:10 a=pGLkceISAAAA:8 a=g2Kqcd2lAAAA:8 a=67BIL_jfAAAA:8 a=lRBSXoDDAAAA:8 a=NEAV23lmAAAA:8 a=Xf62oqlKPdb91QcQyoAA:9 a=pILNOxqGKmIA:10 Message-ID: <3DC031A7488D4B869834A0D7E503B751@pc1> To: "Levi Morrison" , "Ferenc Kovacs" Cc: , "Yasuo Ohgaki" References: Date: Fri, 26 Jun 2015 16:45:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [PHP-DEV] Move to Fast ZPP? From: php_lists@realplain.com ("Matt Wilmas") Hi Levi, ----- Original Message ----- From: "Levi Morrison" Sent: Wednesday, June 24, 2015 > On Wed, Jun 24, 2015 at 3:21 AM, Ferenc Kovacs wrote: >> On Wed, Jun 24, 2015 at 3:42 AM, Yasuo Ohgaki 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 >>> 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