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.
>
> I can think that we can live with the inflation in CAPS and lines if it’s
> limited to just a few dozen functions. It needs to be clear in the RFC
> though.
>
>
>
> Zeev
>
>
>
> *From:* Dmitry Stogov [mailto:dmitry@zend.com]
> *Sent:* Wednesday, May 28, 2014 3:40 PM
> *To:* Zeev Suraski
> *Cc:* Derick Rethans; Johannes Schlüter; Andrea Faulds; PHP Internals; Bob
> Weinand; Stas Malyshev; Xinchen Hui; Andi Gutmans; Nikita Popov
> *Subject:* Re: [PHP-DEV] [RFC] Fast Parameter Parsing API
>
>
>
> ~70 functions are in the patch.
>
> they selected using profiler feedback from Wordpress home page.
>
> Few functions are selected just to test rare argument specifiers (like 'C').
>
> We may convert few more functions profiling other apps.
>
> Thanks. Dmitry.
>
>
>
>
>
> On Wed, May 28, 2014 at 4:24 PM, Zeev Suraski <zeev@zend.com> wrote:
>
> Are there specific functions you think we should use it that could give us
> a 80/20 gain?
>
>
>
> I didn’t think of it as an optimization we’d only use in ‘sensitive’
> functions, but about wholesale migration from the current APIs to new ones.
>
>
>
> Zeev
>
>
>
> *From:* Dmitry Stogov [mailto:dmitry@zend.com]
> *Sent:* Wednesday, May 28, 2014 3:13 PM
> *To:* Derick Rethans
> *Cc:* Johannes Schlüter; 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
>
>
>
> This API was designed to solve the existing bottleneck (5% CPU time lose).
>
> It's not proposed to be used in all functions, only in few really affected.
>
> Anyone may have their own opinion about readability (someones like Perl,
> others Ada).
>
> I appeal to think not about subjective readability, but about the cost of
> ownership for @internals and PHP users.
>
> Thanks. Dmitry.
>
>
>
> On Wed, May 28, 2014 at 3:49 PM, Derick Rethans <derick@php.net> wrote:
>
> On Fri, 23 May 2014, Johannes Schlüter wrote:
>
>> 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:
>>>
>>>> Please take a look at https://wiki.php.net/rfc/fast_zpp
>>>>
>>>> Thanks. Dmitry.
>>>
>>> This looks like a great idea. I like how it’s not only faster, but
>>> it seems to be more readable.
>>
>> 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.
>
> I don't find it more readable either. From 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)
> ?
>
> I know the old API is not going away, but I'm not just sure about this
> one...
>
>
>
>> If we break APIs anyways: Can't we go for C++ which allows providing
>> high level APIs with high performance ...
>
> no :-)
>
> cheers,
> Derick
>
> --
> 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