Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74578
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.83 as permitted sender)
Message-ID: <BLU436-SMTP1420DB40160CB874212EA07E2250@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_894CC0AA-A73F-46DD-BB7E-69C1BA753888"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
In-Reply-To: <0a9e99300cfc9a7018878debffdb1abc@mail.gmail.com>
Date: Wed, 28 May 2014 16:29:41 +0200
CC: Dmitry Stogov <dmitry@zend.com>,
 PHP Internals <internals@lists.php.net>
References: <CA+9eiLuknJ7am5jU4WBN7fGXUcZtbb6axsji8ZnydCJ4P-O9hw@mail.gmail.com> <79B69A20-15AD-4C07-B026-61C2C9DEBBE5@ajf.me>	<1400851698.2870.9315.camel@guybrush> <alpine.DEB.2.10.1405281247260.5108@whisky.home.derickrethans.nl> <CA+9eiLt_sgNVGRT-m+70SNjztk4fUWVS329hsiNzjPN9z+3Q7A@mail.gmail.com> <eb433afa67ea7d3fea56596f3c597169@mail.gmail.com> <CA+9eiLvvtBDKnjVa+FExEBkJSOmn2H_+R0byrJDxa+Z4FepwWA@mail.gmail.com> <0a9e99300cfc9a7018878debffdb1abc@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] Fast Parameter Parsing API
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_894CC0AA-A73F-46DD-BB7E-69C1BA753888
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"

Again, we've already talked about the syntax a bit.

We have also other possibilities like:
zend_parse_parameters(Z_PARAM_ARRAY(input) Z_PARAM_LONG(offset) =
Z_PARAM_OPTIONAL Z_PARAM_ZVAL(z_length) Z_PARAM_BOOL(preserve_keys))
Or even shorter:
zend_parse_parameters(ZP_ARRAY(input) ZP_LONG(offset) ZP_OPTIONAL =
ZP_ZVAL(z_length) ZP_BOOL(preserve_keys))
I think especially the latter is nicely readable and relatively short.

I updated the RFC with those above
And I've changed voting choices a bit:
https://wiki.php.net/rfc/fast_zpp#proposed_voting_choices

Am 28.5.2014 um 14:57 schrieb Zeev Suraski <zeev@zend.com>:
> FWIW, if we use it only in a small subset of the functions that we =
deem
> performance-sensitive, I think it makes a whole lot more sense.
>=20
> I can think that we can live with the inflation in CAPS and lines if =
it=92s
> limited to just a few dozen functions.  It needs to be clear in the =
RFC
> though.
>=20
>=20
>=20
> Zeev
>=20
>=20
>=20
> *From:* Dmitry Stogov [mailto:dmitry@zend.com]
> *Sent:* Wednesday, May 28, 2014 3:40 PM
> *To:* Zeev Suraski
> *Cc:* Derick Rethans; Johannes Schl=FCter; Andrea Faulds; PHP =
Internals; Bob
> Weinand; Stas Malyshev; Xinchen Hui; Andi Gutmans; Nikita Popov
> *Subject:* Re: [PHP-DEV] [RFC] Fast Parameter Parsing API
>=20
>=20
>=20
> ~70 functions are in the patch.
>=20
> they selected using profiler feedback from Wordpress home page.
>=20
> Few functions are selected just to test rare argument specifiers (like =
'C').
>=20
> We may convert few more functions profiling other apps.
>=20
> Thanks. Dmitry.
>=20
>=20
>=20
>=20
>=20
> On Wed, May 28, 2014 at 4:24 PM, Zeev Suraski <zeev@zend.com> wrote:
>=20
> Are there specific functions you think we should use it that could =
give us
> a 80/20 gain?
>=20
>=20
>=20
> I didn=92t think of it as an optimization we=92d only use in =
=91sensitive=92
> functions, but about wholesale migration from the current APIs to new =
ones.
>=20
>=20
>=20
> Zeev
>=20
>=20
>=20
> *From:* Dmitry Stogov [mailto:dmitry@zend.com]
> *Sent:* Wednesday, May 28, 2014 3:13 PM
> *To:* Derick Rethans
> *Cc:* Johannes Schl=FCter; Andrea Faulds; PHP Internals; Bob Weinand; =
Stas
> Malyshev; Zeev Suraski; Xinchen Hui; Andi Gutmans; Nikita Popov
> *Subject:* Re: [PHP-DEV] [RFC] Fast Parameter Parsing API
>=20
>=20
>=20
> This API was designed to solve the existing bottleneck (5% CPU time =
lose).
>=20
> It's not proposed to be used in all functions, only in few really =
affected.
>=20
> Anyone may have their own opinion about readability (someones like =
Perl,
> others Ada).
>=20
> I appeal to think not about subjective readability, but about the cost =
of
> ownership for @internals and PHP users.
>=20
> Thanks. Dmitry.
>=20
>=20
>=20
> On Wed, May 28, 2014 at 3:49 PM, Derick Rethans <derick@php.net> =
wrote:
>=20
> On Fri, 23 May 2014, Johannes Schl=FCter wrote:
>=20
>> On Fri, 2014-05-23 at 13:52 +0100, Andrea Faulds wrote:
>>> On 23 May 2014, at 12:36, Dmitry Stogov <dmitry@zend.com> wrote:
>>>=20
>>>> Please take a look at https://wiki.php.net/rfc/fast_zpp
>>>>=20
>>>> Thanks. Dmitry.
>>>=20
>>> This looks like a great idea. I like how it=92s not only faster, but
>>> it seems to be more readable.
>>=20
>> More readable? - I feel exactly the opposite. Yes, we get rid of void
>> pointers but use a pattern easy to understand. This looks like macro
>> hell.
>=20
> I don't find it more readable either. =46rom a single line, it goes to =
7,
> and what if there are three different zpp calls (like in
> https://github.com/php/php-src/blob/master/ext/date/php_date.c#L4393) =
?
>=20
> I know the old API is not going away, but I'm not just sure about this
> one...
>=20
>=20
>=20
>> If we break APIs anyways: Can't we go for C++ which allows providing
>> high level APIs with high performance ...
>=20
> no :-)
>=20
> cheers,
> Derick
>=20
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> Posted with an email client that doesn't mangle email: alpine



Bob





--Apple-Mail=_894CC0AA-A73F-46DD-BB7E-69C1BA753888--