After a long time… back to our fast_zpp RFC.
Initially Dmitry proposed to have two different APIs, one for the fast version, one for current version:
#if FAST_ZPP
/* new API /
#else
/ old style zend_parse_parameters API */
#endif
I don't really like the idea of having two different APIs, so I'd rather propose to use one same public API for both.
That API should, depending on some compile-time flag (per file or globally in zend_API.h), either convert to the usual variadic style function, or expand to the new fast variant of API parsing (with directly inlining parameter type specific functions).
What do you think about having one unified API for both, instead of the current (like it's in some places in master branch currently)?
(p.s.: The rewrite of the current API can be done safely via some PHP script I wrote)
Also, there is the question about how to structure the API; we (I and Dmitry) basically have now two different proposals:
ZEND_PARSE_PARAMETERS_START(3, 5)
Z_PARAM_ZVAL(regex)
Z_PARAM_ZVAL(replace)
Z_PARAM_ZVAL(subject)
Z_PARAM_OPTIONAL
Z_PARAM_LONG(limit)
Z_PARAM_ZVAL_EX(zcount, 0, 1)
ZEND_PARSE_PARAMETERS_END_EX(return);
OR
zend_parse_parameters(ZPP_ZVAL(regex) ZPP_ZVAL(replace) ZPP_ZVAL(subject) ZPP_OPTIONAL ZPP_LONG(limit) ZPP_ZVAL_EX(zcount, ZPP_BY_REF), {
return;
})
We'd like to have some discussions about what API to use for the next years. If you have some better API, feel free to propose it.
Thanks,
Bob
After a long time… back to our fast_zpp RFC.
Initially Dmitry proposed to have two different APIs, one for the fast version, one for current version:
#if FAST_ZPP
/* new API /
#else
/ old style zend_parse_parameters API */
#endifI don't really like the idea of having two different APIs, so I'd rather propose to use one same public API for both.
That API should, depending on some compile-time flag (per file or globally in zend_API.h), either convert to the usual variadic style function, or expand to the new fast variant of API parsing (with directly inlining parameter type specific functions).What do you think about having one unified API for both, instead of the current (like it's in some places in master branch currently)?
(p.s.: The rewrite of the current API can be done safely via some PHP script I wrote)
This is actually quite an interesting idea. If you think about it, there’s no reason the macros couldn’t expand to zend_parse_parameters.
Also, there is the question about how to structure the API; we (I and Dmitry) basically have now two different proposals:
ZEND_PARSE_PARAMETERS_START(3, 5)
Z_PARAM_ZVAL(regex)
Z_PARAM_ZVAL(replace)
Z_PARAM_ZVAL(subject)
Z_PARAM_OPTIONAL
Z_PARAM_LONG(limit)
Z_PARAM_ZVAL_EX(zcount, 0, 1)
ZEND_PARSE_PARAMETERS_END_EX(return);OR
zend_parse_parameters(ZPP_ZVAL(regex) ZPP_ZVAL(replace) ZPP_ZVAL(subject) ZPP_OPTIONAL ZPP_LONG(limit) ZPP_ZVAL_EX(zcount, ZPP_BY_REF), {
return;
})We'd like to have some discussions about what API to use for the next years. If you have some better API, feel free to propose it.
Neither is that good, though I might prefer the first one.
Perhaps we should move this out of functions altogether, and instead have parameter types be attributes of the function? I’m not sure if it’s possible, but it would be awesome if we could just put the types where we have our parameter names in our info structs, and it would just magically call the C function with the right types.
Andrea Faulds
http://ajf.me/
After a long time… back to our fast_zpp RFC.
Initially Dmitry proposed to have two different APIs, one for the fast version, one for current version:
#if FAST_ZPP
/* new API /
#else
/ old style zend_parse_parameters API */
#endifI don't really like the idea of having two different APIs, so I'd
rather propose to use one same public API for both. That API should,
depending on some compile-time flag (per file or globally in
zend_API.h), either convert to the usual variadic style function, or
expand to the new fast variant of API parsing (with directly inlining
parameter type specific functions).
I am going to need an ifdef anyway, once for < PHP 7 and once for >= PHP
7...
What do you think about having one unified API for both, instead of
the current (like it's in some places in master branch currently)?
(p.s.: The rewrite of the current API can be done safely via some PHP
script I wrote)
I think it makes perfect sense to have two styles. Keep the current zpp
that we have, and only optimise it with the much less readable versions
for functions (think strlen()) that are called a lot.
Also, there is the question about how to structure the API; we (I and
Dmitry) basically have now two different proposals:ZEND_PARSE_PARAMETERS_START(3, 5)
Z_PARAM_ZVAL(regex)
Z_PARAM_ZVAL(replace)
Z_PARAM_ZVAL(subject)
Z_PARAM_OPTIONAL
Z_PARAM_LONG(limit)
Z_PARAM_ZVAL_EX(zcount, 0, 1)
ZEND_PARSE_PARAMETERS_END_EX(return);OR
zend_parse_parameters(ZPP_ZVAL(regex) ZPP_ZVAL(replace) ZPP_ZVAL(subject) ZPP_OPTIONAL ZPP_LONG(limit) ZPP_ZVAL_EX(zcount, ZPP_BY_REF), {
return;
})
Both of them very much suck as API compared to:
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ZZZ|lZ", ®ex, &replace, &subject, &limit, &zcount) == FAILURE) {
As I mentioned before, keep the current zpp working, and add a special
one for the functions where a faster one really matters.
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
After a long time… back to our fast_zpp RFC.
Initially Dmitry proposed to have two different APIs, one for the fast
version, one for current version:
#if FAST_ZPP
/* new API /
#else
/ old style zend_parse_parameters API */
#endifI don't really like the idea of having two different APIs, so I'd
rather propose to use one same public API for both. That API should,
depending on some compile-time flag (per file or globally in
zend_API.h), either convert to the usual variadic style function, or
expand to the new fast variant of API parsing (with directly inlining
parameter type specific functions).I am going to need an ifdef anyway, once for < PHP 7 and once for >= PHP
7...What do you think about having one unified API for both, instead of
the current (like it's in some places in master branch currently)?
(p.s.: The rewrite of the current API can be done safely via some PHP
script I wrote)I think it makes perfect sense to have two styles. Keep the current zpp
that we have, and only optimise it with the much less readable versions
for functions (thinkstrlen()) that are called a lot.Also, there is the question about how to structure the API; we (I and
Dmitry) basically have now two different proposals:ZEND_PARSE_PARAMETERS_START(3, 5)
Z_PARAM_ZVAL(regex)
Z_PARAM_ZVAL(replace)
Z_PARAM_ZVAL(subject)
Z_PARAM_OPTIONAL
Z_PARAM_LONG(limit)
Z_PARAM_ZVAL_EX(zcount, 0, 1)
ZEND_PARSE_PARAMETERS_END_EX(return);OR
zend_parse_parameters(ZPP_ZVAL(regex) ZPP_ZVAL(replace)
ZPP_ZVAL(subject) ZPP_OPTIONAL ZPP_LONG(limit) ZPP_ZVAL_EX(zcount,
ZPP_BY_REF), {
return;
})Both of them very much suck as API compared to:
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ZZZ|lZ", ®ex,
&replace, &subject, &limit, &zcount) == FAILURE) {
scanf() is suck as well, but I agree, that it makes no sense to switch from
one bad but working solution to another one.
As I mentioned before, keep the current zpp working, and add a special
one for the functions where a faster one really matters.
This was an original proposal, that is already in php-master, but I
promised that we will discuss it in some point.
Thanks. Dmitry.
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
I like the idea of having a single syntax for all cases, but I don't like
the syntax you propose.
In my opinion, it's syntactically inconsistent, less readable and more
error prone, than the old one (sscanf based) and the FAST_ZPP one that is
already in php-master.
I would also prefer to have an ability to select which function should use
"fast" parameter parsing individually.
(You propose use "fast" for all functions, or enable it per extension)
Using "fast" parsing for all functions may significantly increase code size
and slowdown execution, but we won't know it for sure until we didn't try
it.
Anyway, if we find a good single syntax, we must be able to solve technical
problems.
Opinions and other syntax ideas would help us to do our best :)
Thanks. Dmitry.
After a long time… back to our fast_zpp RFC.
Initially Dmitry proposed to have two different APIs, one for the fast
version, one for current version:
#if FAST_ZPP
/* new API /
#else
/ old style zend_parse_parameters API */
#endifI don't really like the idea of having two different APIs, so I'd rather
propose to use one same public API for both.
That API should, depending on some compile-time flag (per file or globally
in zend_API.h), either convert to the usual variadic style function, or
expand to the new fast variant of API parsing (with directly inlining
parameter type specific functions).What do you think about having one unified API for both, instead of the
current (like it's in some places in master branch currently)?
(p.s.: The rewrite of the current API can be done safely via some PHP
script I wrote)Also, there is the question about how to structure the API; we (I and
Dmitry) basically have now two different proposals:ZEND_PARSE_PARAMETERS_START(3, 5)
Z_PARAM_ZVAL(regex)
Z_PARAM_ZVAL(replace)
Z_PARAM_ZVAL(subject)
Z_PARAM_OPTIONAL
Z_PARAM_LONG(limit)
Z_PARAM_ZVAL_EX(zcount, 0, 1)
ZEND_PARSE_PARAMETERS_END_EX(return);OR
zend_parse_parameters(ZPP_ZVAL(regex) ZPP_ZVAL(replace) ZPP_ZVAL(subject)
ZPP_OPTIONAL ZPP_LONG(limit) ZPP_ZVAL_EX(zcount, ZPP_BY_REF), {
return;
})We'd like to have some discussions about what API to use for the next
years. If you have some better API, feel free to propose it.Thanks,
Bob
I like the idea of having a single syntax for all cases, but I don't like
the syntax you propose.
In my opinion, it's syntactically inconsistent, less readable and more
error prone, than the old one (sscanf based) and the FAST_ZPP one that is
already in php-master.
I do not like any of the new ones, FAST_ZPP included. I find them all
error prones and not as KISS as what we have now.
As I understand correctly the only reason we have this discussion is
the performance impact of zpp with some functions, mainly
ZEND_FUNCTIONs. What prevents us to make them operators? That may
break things like call_user_func("strlen", $arg), array_map and the
likes but there may have ways to limit the BC breaks here too. If it
avoid an endless discussion about APIs, it is worse the effort to try
it.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
As I understand correctly the only reason we have this discussion is
the performance impact of zpp with some functions, mainly
ZEND_FUNCTIONs. What prevents us to make them operators? That may
break things like call_user_func("strlen", $arg), array_map and the
There's also an issue that strlen("foo") may mean a different thing if
you're in a namespace. So there may be a challenge to do this on
compiler level, at least in the obvious way. But maybe there's a way
around it, so theoretically we could make compiler treat strlen() as
operator, or, more precisely, as an inline function looking like C
function with parameters passed in registers. I.e., what I mean is
skipping the whole parameter-passing and receiving altogether and just
give it the slot where the variable lives. Of course, it would work only
with strlen() and such which do not modify the argument and hardly do
anything with it at all, and strlen would essentially have to have two
implementations - one for "inline" usage and one for "normal" usage
($foo(), call_user_func(), etc.). But since 99% of actual usage would be
"inline" it may still be beneficial.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
It's already done for strlen() - ZEND_STRLEN opcode (and few other
functions).
But it make no sense to convert all useful functions into opcodes.
We need an ability of fast parameter parsing anyway.
Thanks. Dmitry.
On Fri, Sep 5, 2014 at 5:55 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
As I understand correctly the only reason we have this discussion is
the performance impact of zpp with some functions, mainly
ZEND_FUNCTIONs. What prevents us to make them operators? That may
break things like call_user_func("strlen", $arg), array_map and theThere's also an issue that strlen("foo") may mean a different thing if
you're in a namespace. So there may be a challenge to do this on
compiler level, at least in the obvious way. But maybe there's a way
around it, so theoretically we could make compiler treatstrlen()as
operator, or, more precisely, as an inline function looking like C
function with parameters passed in registers. I.e., what I mean is
skipping the whole parameter-passing and receiving altogether and just
give it the slot where the variable lives. Of course, it would work only
withstrlen()and such which do not modify the argument and hardly do
anything with it at all, and strlen would essentially have to have two
implementations - one for "inline" usage and one for "normal" usage
($foo(),call_user_func(), etc.). But since 99% of actual usage would be
"inline" it may still be beneficial.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
It's already done for
strlen()- ZEND_STRLEN opcode (and few other
functions).
But it make no sense to convert all useful functions into opcodes.
We need an ability of fast parameter parsing anyway.
Got that, but hard to say for which functions. Right now it is used
for almost everything, reflection, pcre, etc. I can hardly think about
why a faster zpp may impact these functions. Do you have an exhaustive
list?
I am not saying it is not good to rethink zpp but if we do then the
gain from a usability point of view must be much better. I do not see
that now (yes, subjective but...).
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
most of the functions converted to FAST_ZPP were collected by profiling or
real life apps.
These functions spent significant part of the time in
zend_parse_parameters() because they are short themselves or because they
are called very often.
few functions were added to test some "exotic" type specifiers (like "C" or
"L").
Thanks. Dmitry.
It's already done for
strlen()- ZEND_STRLEN opcode (and few other
functions).
But it make no sense to convert all useful functions into opcodes.
We need an ability of fast parameter parsing anyway.Got that, but hard to say for which functions. Right now it is used
for almost everything, reflection, pcre, etc. I can hardly think about
why a faster zpp may impact these functions. Do you have an exhaustive
list?I am not saying it is not good to rethink zpp but if we do then the
gain from a usability point of view must be much better. I do not see
that now (yes, subjective but...).Cheers,
Pierre
@pierrejoye | http://www.libgd.org
most of the functions converted to FAST_ZPP were collected by profiling or
real life apps.
These functions spent significant part of the time in
zend_parse_parameters() because they are short themselves or because they
are called very often.
Ok. So there is no real short list of functions actually needing fast
zpp. I am not sure about the actual impact on pcre or reflection
functions, no matter how often they are called. They are going to be
slower than each anyway, f.e. On the other hands, some standard
functions (each, prev and co) fit in the same area than strlen, no?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
no.
Dmitry.
most of the functions converted to FAST_ZPP were collected by profiling
or
real life apps.
These functions spent significant part of the time in
zend_parse_parameters() because they are short themselves or because they
are called very often.Ok. So there is no real short list of functions actually needing fast
zpp. I am not sure about the actual impact on pcre or reflection
functions, no matter how often they are called. They are going to be
slower than each anyway, f.e. On the other hands, some standard
functions (each, prev and co) fit in the same area than strlen, no?Cheers,
Pierre
@pierrejoye | http://www.libgd.org