Move to Fast ZPP? - Externals

10 years ago by Dmitry Stogov — view source

unread

We should NOT use it everywhere. It'll lead to code bloat.

Thanks. Dmitry.

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 +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?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

10 years ago by Yasuo Ohgaki — view source

unread

Hi Dmitry,

We should NOT use it everywhere. It'll lead to code bloat.

OK. Thank you.
I'll use it only for functions called many times. e.g. pg_fetch_*().
Should I use #ifndef FAST_ZPP?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Dmitry Stogov — view source

unread

Hi Dmitry,

We should NOT use it everywhere. It'll lead to code bloat.

OK. Thank you.
I'll use it only for functions called many times. e.g. pg_fetch_*().
Should I use #ifndef FAST_ZPP?

I think, ZPP overhead of pg_fetch() is insignificant in comparison to DB
access.
I didn't change API for ext/mysql* only for really often used functions.

Before optimizing something, you'll need to check if you really have a
bottleneck.
Run some application with callgrind, then check how many times ZPP called
from zip_pg_fetch() and its relative cost.
If it less than 0.05%, it makes no sense to do anything.

Over-optimization may make more harm than benefits.

Thanks. Dmitry.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Matt Wilmas — view source

unread

Hi Dmitry, all,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Wednesday, June 24, 2015

We should NOT use it everywhere. It'll lead to code bloat.

Thanks. Dmitry.

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 +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?

Right, FAST_ZPP makes code larger, inlining stuff in each function, etc.

But I was wondering, is there any more that can be done to optimize the
slowness of the traditional ZPP? I don't recall any changes being made to
it in the last 12-18 months to speed it up at all...

Is there a particular part that's making it slow? Is it the string of
param types? Is it the va_arg's, that doesn't allow the call to be
optimized as well and/or the arg fetching that's slow?

I know there were the syntax issues as well, but would using something like
a single param (array pointer) for param types/values help at all?

Or is it just the internals of ZPP that are inherently slow...? :-/ Or
that's fine but the "mechanism" of getting there is the issue?

Thanks,
Matt

10 years ago by Dmitry Stogov — view source

unread

On Wed, Jun 24, 2015 at 1:35 PM, Matt Wilmas php_lists@realplain.com
wrote:

Hi Dmitry, all,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Wednesday, June 24, 2015

We should NOT use it everywhere. It'll lead to code bloat.

Thanks. Dmitry.
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 +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?
Right, FAST_ZPP makes code larger, inlining stuff in each function, etc.

But I was wondering, is there any more that can be done to optimize the
slowness of the traditional ZPP? I don't recall any changes being made to
it in the last 12-18 months to speed it up at all...

Is there a particular part that's making it slow? Is it the string of
param types? Is it the va_arg's, that doesn't allow the call to be
optimized as well and/or the arg fetching that's slow?

I know there were the syntax issues as well, but would using something
like a single param (array pointer) for param types/values help at all?

Or is it just the internals of ZPP that are inherently slow...? :-/ Or
that's fine but the "mechanism" of getting there is the issue?

The traditional ZPP is actually a et another interpreter that reads
specification string char by char and perform actions.
And interpreters are usually slower.

I think it may be improved, but I don't expect significant overall
improvement because of that.
Now, the cumulative overhead of traditional ZPP on wordpress is ~0.4%.
Even if we make it 2 times faster, we may get just 0.2% overall speed up.

Thanks. Dmitry.

Thanks,
Matt

9 years ago by Matt Wilmas — view source

unread

Hi Dmitry, all,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Thursday, June 25, 2015

On Wed, Jun 24, 2015 at 1:35 PM, Matt Wilmas php_lists@realplain.com
wrote:

Hi Dmitry, all,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Wednesday, June 24, 2015

We should NOT use it everywhere. It'll lead to code bloat.

Thanks. Dmitry.

[...]

Right, FAST_ZPP makes code larger, inlining stuff in each function, etc.

But I was wondering, is there any more that can be done to optimize the
slowness of the traditional ZPP? I don't recall any changes being made
to
it in the last 12-18 months to speed it up at all...

Is there a particular part that's making it slow? Is it the string of
param types? Is it the va_arg's, that doesn't allow the call to be
optimized as well and/or the arg fetching that's slow?

I know there were the syntax issues as well, but would using something
like a single param (array pointer) for param types/values help at all?

Or is it just the internals of ZPP that are inherently slow...? :-/ Or
that's fine but the "mechanism" of getting there is the issue?

The traditional ZPP is actually a et another interpreter that reads
specification string char by char and perform actions.
And interpreters are usually slower.

I think it may be improved, but I don't expect significant overall
improvement because of that.
Now, the cumulative overhead of traditional ZPP on wordpress is ~0.4%.
Even if we make it 2 times faster, we may get just 0.2% overall speed up.

Yeah, I knew how the traditional ZPP worked, just wondered about any certain
"problem area." :-) But it seems it's just the whole thing, so much it's
doing, besides just the "string format interpretation."

First, only fractions of a % old ZPP is using on WordPress now? That
doesn't make sense to me... On fast_zpp wiki page, you said last year it
was taking ~6% of time on Wordpress (before FAST_ZPP, of course). And
changing key/hot functions to FAST_ZPP saved ~2.5% time. So that should
have left a few percent of time used by traditional ZPP.

But everything else has gotten faster since then, so therefore, for an
unchanged old ZPP, its percentage contribution should have gone up? Well,
anyway...

I went ahead and tried implementing my idea (had been awhile since I really
looked at the FAST_ZPP stuff, and didn't realize it was as simple to work
from). :-)

It uses the same syntax as "FAST_ZPP" (if we/others like/prefer that) and a
zend_FAST_parse_parameters() function. Code size should be about same as
before, maybe a few more bytes depending on instructions needed (still
thinking/adjusting).

It seems to have pretty good performance increase! BTW, in quick testing, I
don't see old ZPP using 90% of time even with empty/dummy function. Just
about 50% (with or without ZTS)...

I didn't know how close we could get to the inlined FAST_ZPP, but it seems
the majority of the way there: ~70% in the simple case. (To be clear, 3x
faster than old.) This was on Windows XP with ancient VC9.

I don't have a patch ready for you to look at yet, since I didn't finish
changing the macros, etc.

It would be awesome if this could start being used throughout the codebase,
and not just functions with preferential treatment. :-P Maybe you'd even
switch back from the inlined version in some places, if smaller code would
be better.

Thanks. Dmitry.

Matt

9 years ago by Dmitry Stogov — view source

unread

On Sat, Jun 27, 2015 at 12:36 AM, Matt Wilmas php_lists@realplain.com
wrote:

Hi Dmitry, all,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Thursday, June 25, 2015

On Wed, Jun 24, 2015 at 1:35 PM, Matt Wilmas php_lists@realplain.com

wrote:

Hi Dmitry, all,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Wednesday, June 24, 2015

We should NOT use it everywhere. It'll lead to code bloat.

Thanks. Dmitry.

[...]

Right, FAST_ZPP makes code larger, inlining stuff in each function, etc.

But I was wondering, is there any more that can be done to optimize the
slowness of the traditional ZPP? I don't recall any changes being made
to
it in the last 12-18 months to speed it up at all...

Is there a particular part that's making it slow? Is it the string of
param types? Is it the va_arg's, that doesn't allow the call to be
optimized as well and/or the arg fetching that's slow?

I know there were the syntax issues as well, but would using something
like a single param (array pointer) for param types/values help at all?

Or is it just the internals of ZPP that are inherently slow...? :-/ Or
that's fine but the "mechanism" of getting there is the issue?

The traditional ZPP is actually a et another interpreter that reads
specification string char by char and perform actions.
And interpreters are usually slower.

I think it may be improved, but I don't expect significant overall
improvement because of that.
Now, the cumulative overhead of traditional ZPP on wordpress is ~0.4%.
Even if we make it 2 times faster, we may get just 0.2% overall speed up.

Yeah, I knew how the traditional ZPP worked, just wondered about any
certain "problem area." :-) But it seems it's just the whole thing, so
much it's doing, besides just the "string format interpretation."

First, only fractions of a % old ZPP is using on WordPress now? That
doesn't make sense to me... On fast_zpp wiki page, you said last year it
was taking ~6% of time on Wordpress (before FAST_ZPP, of course). And
changing key/hot functions to FAST_ZPP saved ~2.5% time. So that should
have left a few percent of time used by traditional ZPP.

But everything else has gotten faster since then, so therefore, for an
unchanged old ZPP, its percentage contribution should have gone up? Well,
anyway...

I went ahead and tried implementing my idea (had been awhile since I
really looked at the FAST_ZPP stuff, and didn't realize it was as simple to
work from). :-)

It uses the same syntax as "FAST_ZPP" (if we/others like/prefer that) and
a zend_FAST_parse_parameters() function. Code size should be about same as
before, maybe a few more bytes depending on instructions needed (still
thinking/adjusting).

It seems to have pretty good performance increase! BTW, in quick testing,
I don't see old ZPP using 90% of time even with empty/dummy function. Just
about 50% (with or without ZTS)...

I didn't know how close we could get to the inlined FAST_ZPP, but it seems
the majority of the way there: ~70% in the simple case. (To be clear, 3x
faster than old.) This was on Windows XP with ancient VC9.

I don't have a patch ready for you to look at yet, since I didn't finish
changing the macros, etc.

It would be awesome if this could start being used throughout the
codebase, and not just functions with preferential treatment. :-P Maybe
you'd even switch back from the inlined version in some places, if smaller
code would be better.

Send you implementation as soon as it's ready. I'll test it.

Thanks. Dmitry.

Thanks. Dmitry.

Matt

9 years ago by Matt Wilmas — view source

unread

Hi again Dmitry, all,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Monday, June 29, 2015

On Sat, Jun 27, 2015 at 12:36 AM, Matt Wilmas php_lists@realplain.com
wrote:

Hi Dmitry, all,

[...]

Yeah, I knew how the traditional ZPP worked, just wondered about any
certain "problem area." :-) But it seems it's just the whole thing, so
much it's doing, besides just the "string format interpretation."

First, only fractions of a % old ZPP is using on WordPress now? That
doesn't make sense to me... On fast_zpp wiki page, you said last year it
was taking ~6% of time on Wordpress (before FAST_ZPP, of course). And
changing key/hot functions to FAST_ZPP saved ~2.5% time. So that should
have left a few percent of time used by traditional ZPP.

But everything else has gotten faster since then, so therefore, for an
unchanged old ZPP, its percentage contribution should have gone up?
Well,
anyway...

I went ahead and tried implementing my idea (had been awhile since I
really looked at the FAST_ZPP stuff, and didn't realize it was as simple
to
work from). :-)

It uses the same syntax as "FAST_ZPP" (if we/others like/prefer that) and
a zend_FAST_parse_parameters() function. Code size should be about same
as
before, maybe a few more bytes depending on instructions needed (still
thinking/adjusting).

It seems to have pretty good performance increase! BTW, in quick
testing,
I don't see old ZPP using 90% of time even with empty/dummy function.
Just
about 50% (with or without ZTS)...

I didn't know how close we could get to the inlined FAST_ZPP, but it
seems
the majority of the way there: ~70% in the simple case. (To be clear, 3x
faster than old.) This was on Windows XP with ancient VC9.

I don't have a patch ready for you to look at yet, since I didn't finish
changing the macros, etc.

It would be awesome if this could start being used throughout the
codebase, and not just functions with preferential treatment. :-P Maybe
you'd even switch back from the inlined version in some places, if
smaller
code would be better.

Send you implementation as soon as it's ready. I'll test it.

Just an update... I didn't abandon this; quite the opposite! I thought I'd
just put the finishing touches on my implementation and have it to you
almost a week ago. After my rough initial test version, I made some
obvious, simple changes to reduce instructions/code size (slightly). And
then analyzing different stuff with GCC and MSVC to see if it could be
improved more (not really since fairly straightforward), etc...

~5 days ago when I was done messing and changed the macros to recompile the
existing FAST_ZPP parts, I didn't know what the size difference would be vs
no FAST_ZPP (traditional). I had overestimated the savings ("maybe a few
more bytes" for instructions). It was in the 30-45% range of your inlined
version.

I made a change to save instructions, but, strangely, it didn't really have
the effect on size I thought it would. :-/

BTW, the improvement on Linux with GCC 4.8 was about the same: ~70% of
inlined. So roughly ~2/3 speed for ~1/3 space. I also finally installed
Valgrind and used Callgrind for the first time. Simple. :^) About same
relative reduction in instructions.

I really wanted the code size to be smaller if this could get widespread
use, and started wondering, "What if...?", "How?", "Why not?", "But..."

Then I had a new idea, but wasn't sure what the compilers would do with it.
So I spent Sunday prototyping a couple key parts of it outside of PHP. GCC
can make a HUGE mess of it, but easily worked around. So it looks good,
even better than the ideal I had imagined. Now I just have to do it for
PHP...

This way saves the lea instructions for each &dest variable (like the inline
version), and then some. And just earlier I realized there's a way to save
the other instructions (while using the same macro syntax), which would also
apply to the previous implementation.

So ideally, this means at the CALL site, we should be able to have the
zend_fast_parse_... function call: Just mov+mov+lea+call on 64-bit, and
that's it. The rest of the stuff (a good amount) can be COMPLETELY
optimized away! :-O

And in the parse_... function, compared to the inline FAST_ZPP, that
should get it down to about 3 dozen more instructions per parameter: while +
switch + checks in zend_parse_arg_* that would get optimized away when
inlined.

Well, I'll send the implementation(s) for you to test as soon as I can!

Thanks. Dmitry.

Matt

9 years ago by Matt Wilmas — view source

unread

Hi again Dmitry, all,

Hopefully the final update on this, before all is revealed... :-)

----- Original Message -----
From: "Matt Wilmas"
Sent: Tuesday, July 07, 2015

Hi again Dmitry, all,

[...]

Just an update... I didn't abandon this; quite the opposite! I thought
I'd just put the finishing touches on my implementation and have it to you
almost a week ago. After my rough initial test version, I made some
obvious, simple changes to reduce instructions/code size (slightly). And
then analyzing different stuff with GCC and MSVC to see if it could be
improved more (not really since fairly straightforward), etc...

~5 days ago when I was done messing and changed the macros to recompile
the existing FAST_ZPP parts, I didn't know what the size difference would
be vs no FAST_ZPP (traditional). I had overestimated the savings ("maybe
a few more bytes" for instructions). It was in the 30-45% range of your
inlined version.

I made a change to save instructions, but, strangely, it didn't really
have the effect on size I thought it would. :-/

BTW, the improvement on Linux with GCC 4.8 was about the same: ~70% of
inlined. So roughly ~2/3 speed for ~1/3 space. I also finally installed
Valgrind and used Callgrind for the first time. Simple. :^) About same
relative reduction in instructions.

I really wanted the code size to be smaller if this could get widespread
use, and started wondering, "What if...?", "How?", "Why not?", "But..."

Then I had a new idea, but wasn't sure what the compilers would do with
it. So I spent Sunday prototyping a couple key parts of it outside of PHP.
GCC can make a HUGE mess of it, but easily worked around. So it looks
good, even better than the ideal I had imagined. Now I just have to do it
for PHP...

This way saves the lea instructions for each &dest variable (like the
inline version), and then some. And just earlier I realized there's a way
to save the other instructions (while using the same macro syntax), which
would also apply to the previous implementation.

So ideally, this means at the CALL site, we should be able to have the
zend_fast_parse_... function call: Just mov+mov+lea+call on 64-bit, and
that's it. The rest of the stuff (a good amount) can be COMPLETELY
optimized away! :-O

And in the parse_... function, compared to the inline FAST_ZPP, that
should get it down to about 3 dozen more instructions per parameter: while

switch + checks in zend_parse_arg_* that would get optimized away when
inlined.

Well, I'll send the implementation(s) for you to test as soon as I can!

I tried to rush and finish things up before the weekend 2 weeks ago, but
it took me too long to get the macros sorted out and working right. :-/
Sorry for the delay, but more and better goodness should now be included.
The extra time allowed me to "relax and take notes" (Notorious B.I.G.),
however. :-D

So yeah, that was all working 10 days ago. Then I realized more function
param data could be packed together which saved another mov instruction --
so at the call site, it's just mov+lea+call on 64-bit (since execute_data is
already in %rdi). There's nothing else (ignoring checking return
value/return on error, etc.), and each &dest variable is filled in even
though their address isn't taken (thanks to compiler magic). The only
exceptions are FUNC (4 instructions I think) and OBJECT_OF_CLASS and
VARIADIC (1 instruction) types.

Unfortunately (only because I said "same macro syntax," but no big deal),
the syntax had to be changed, from:

ZEND_PARSE_PARAMETERS_START_EX
Z_PARAM_(...)
Z_PARAM_(...)
ZEND_PARSE_PARAMETERS_END[_EX]

to

ZEND_PARSE_PARAMETERS_START_EX( // Parentheses
Z_PARAM_(...), // Comma-separated
Z_PARAM_(...)
) ZEND_PARSE_PARAMETERS_END[_EX]

Overall, the code size is reduced (vs traditional ZPP), but the file size
isn't (static stuff in rodata or whatever), which was a bit surprising,
although most of these PHP functions don't have many parameters...

The biggest size savings actually came from the simple initial optimization
of zend_parse_params_none(). Down to almost nothing, much faster, and saved
4KB on my --disable-all builds.

NEW GOODNESS -- What would of course be nice to have is a big optimization
of the traditional zend_parse[_method]_parameters[_ex|_throw] to avoid
changing them all. And it seems some people, like Derick, prefer it.

Of course the obvious way I first had in mind weeks ago was to simply parse
its format string faster (once-ish) at runtime, and then feed it to this new
FAST_parse function. Should give at least 2x speedup I figured. But with
this latest implementation, where the function should probably now be called
parse_parameters_ARRAY instead of fast_parse, it would need a second pass
after parsing the string. Not a huge deal, but...

What would be really nice is to have the compiler parse the format string,
at compile time, and use the new system directly. And... that should be
possible!! 8-)

Last week I figured GCC's "statement expressions" [1] could be used, which
most compilers seem to support, except MSVC. But just over the weekend I
realized an inline function could be used with a compound literal (for the
varargs), which is also supported in the latest MSVC versions. Awesome!

And again, fear not, ALL the code can be completely removed by the compiler,
leaving only movb instructions instead of lea+mov/push for the traditional
ZPP function call. So, better than my initial implementation(s), and nearly
the same as my final macro version! I was just testing prototypes of
portions with GCC yesterday, which does fine after adjusting to not generate
horribly stupid code.

Now to implement it into PHP ASAP! Then I'll save a few more
banches/instructions in the parse function (specialized for common cases;
some useless GCC instructions), comment and clean up my experimental mess,
and write up some explanation of the changes before sending patch. Oh, and
I should verify what Clang does with the code as well...

Stay tuned!

[1] https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

Matt

9 years ago by Dmitry Stogov — view source

unread

Hi Matt,

On Wed, Jul 22, 2015 at 11:16 PM, Matt Wilmas php_lists@realplain.com
wrote:

Hi again Dmitry, all,

Hopefully the final update on this, before all is revealed... :-)

----- Original Message -----
From: "Matt Wilmas"
Sent: Tuesday, July 07, 2015

Hi again Dmitry, all,

[...]

Just an update... I didn't abandon this; quite the opposite! I thought
I'd just put the finishing touches on my implementation and have it to you
almost a week ago. After my rough initial test version, I made some
obvious, simple changes to reduce instructions/code size (slightly). And
then analyzing different stuff with GCC and MSVC to see if it could be
improved more (not really since fairly straightforward), etc...

~5 days ago when I was done messing and changed the macros to recompile
the existing FAST_ZPP parts, I didn't know what the size difference would
be vs no FAST_ZPP (traditional). I had overestimated the savings ("maybe a
few more bytes" for instructions). It was in the 30-45% range of your
inlined version.

I made a change to save instructions, but, strangely, it didn't really
have the effect on size I thought it would. :-/

BTW, the improvement on Linux with GCC 4.8 was about the same: ~70% of
inlined. So roughly ~2/3 speed for ~1/3 space. I also finally installed
Valgrind and used Callgrind for the first time. Simple. :^) About same
relative reduction in instructions.

I really wanted the code size to be smaller if this could get widespread
use, and started wondering, "What if...?", "How?", "Why not?", "But..."

Then I had a new idea, but wasn't sure what the compilers would do with
it. So I spent Sunday prototyping a couple key parts of it outside of PHP.
GCC can make a HUGE mess of it, but easily worked around. So it looks
good, even better than the ideal I had imagined. Now I just have to do it
for PHP...

This way saves the lea instructions for each &dest variable (like the
inline version), and then some. And just earlier I realized there's a way
to save the other instructions (while using the same macro syntax), which
would also apply to the previous implementation.

So ideally, this means at the CALL site, we should be able to have the
zend_fast_parse_... function call: Just mov+mov+lea+call on 64-bit, and
that's it. The rest of the stuff (a good amount) can be COMPLETELY
optimized away! :-O

And in the parse_... function, compared to the inline FAST_ZPP, that
should get it down to about 3 dozen more instructions per parameter: while

switch + checks in zend_parse_arg_* that would get optimized away when
inlined.

Well, I'll send the implementation(s) for you to test as soon as I can!

I tried to rush and finish things up before the weekend 2 weeks ago, but
it took me too long to get the macros sorted out and working right. :-/
Sorry for the delay, but more and better goodness should now be included.
The extra time allowed me to "relax and take notes" (Notorious B.I.G.),
however. :-D

So yeah, that was all working 10 days ago. Then I realized more function
param data could be packed together which saved another mov instruction --
so at the call site, it's just mov+lea+call on 64-bit (since execute_data
is already in %rdi). There's nothing else (ignoring checking return
value/return on error, etc.), and each &dest variable is filled in even
though their address isn't taken (thanks to compiler magic). The only
exceptions are FUNC (4 instructions I think) and OBJECT_OF_CLASS and
VARIADIC (1 instruction) types.

Unfortunately (only because I said "same macro syntax," but no big deal),
the syntax had to be changed, from:

ZEND_PARSE_PARAMETERS_START_EX
Z_PARAM_(...)
Z_PARAM_(...)
ZEND_PARSE_PARAMETERS_END[_EX]

to

ZEND_PARSE_PARAMETERS_START_EX( // Parentheses
Z_PARAM_(...), // Comma-separated
Z_PARAM_(...)
) ZEND_PARSE_PARAMETERS_END[_EX]

Errors in nested macros might be very difficult to understand :(
I would prefer not to use nested macros without a significant gain.

Overall, the code size is reduced (vs traditional ZPP), but the file
size isn't (static stuff in rodata or whatever), which was a bit
surprising, although most of these PHP functions don't have many
parameters...

I may just guess, where this static data came from, because I didn't see
the code yet :)

Thanks. Dmitry.

The biggest size savings actually came from the simple initial
optimization of zend_parse_params_none(). Down to almost nothing, much
faster, and saved 4KB on my --disable-all builds.

NEW GOODNESS -- What would of course be nice to have is a big optimization
of the traditional zend_parse[_method]_parameters[_ex|_throw] to avoid
changing them all. And it seems some people, like Derick, prefer it.

Of course the obvious way I first had in mind weeks ago was to simply
parse its format string faster (once-ish) at runtime, and then feed it to
this new FAST_parse function. Should give at least 2x speedup I figured.
But with this latest implementation, where the function should probably now
be called parse_parameters_ARRAY instead of fast_parse, it would need a
second pass after parsing the string. Not a huge deal, but...

What would be really nice is to have the compiler parse the format
string, at compile time, and use the new system directly. And... that
should be possible!! 8-)

Last week I figured GCC's "statement expressions" [1] could be used, which
most compilers seem to support, except MSVC. But just over the weekend I
realized an inline function could be used with a compound literal (for the
varargs), which is also supported in the latest MSVC versions. Awesome!

And again, fear not, ALL the code can be completely removed by the
compiler, leaving only movb instructions instead of lea+mov/push for the
traditional ZPP function call. So, better than my initial
implementation(s), and nearly the same as my final macro version! I was
just testing prototypes of portions with GCC yesterday, which does fine
after adjusting to not generate horribly stupid code.

Now to implement it into PHP ASAP! Then I'll save a few more
banches/instructions in the parse function (specialized for common cases;
some useless GCC instructions), comment and clean up my experimental mess,
and write up some explanation of the changes before sending patch. Oh, and
I should verify what Clang does with the code as well...

Stay tuned!

[1] https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

Matt

9 years ago by Matt Wilmas — view source

unread

Hi Dmitry,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Monday, August 03, 2015

Hi Matt,

On Wed, Jul 22, 2015 at 11:16 PM, Matt Wilmas php_lists@realplain.com
wrote:

Hi again Dmitry, all,

Hopefully the final update on this, before all is revealed... :-)

[...]

I tried to rush and finish things up before the weekend 2 weeks ago,
but
it took me too long to get the macros sorted out and working right. :-/
Sorry for the delay, but more and better goodness should now be included.
The extra time allowed me to "relax and take notes" (Notorious B.I.G.),
however. :-D

So yeah, that was all working 10 days ago. Then I realized more function
param data could be packed together which saved another mov
instruction --
so at the call site, it's just mov+lea+call on 64-bit (since execute_data
is already in %rdi). There's nothing else (ignoring checking return
value/return on error, etc.), and each &dest variable is filled in even
though their address isn't taken (thanks to compiler magic). The only
exceptions are FUNC (4 instructions I think) and OBJECT_OF_CLASS and
VARIADIC (1 instruction) types.

Unfortunately (only because I said "same macro syntax," but no big deal),
the syntax had to be changed, from:

ZEND_PARSE_PARAMETERS_START_EX
Z_PARAM_(...)
Z_PARAM_(...)
ZEND_PARSE_PARAMETERS_END[_EX]

to

ZEND_PARSE_PARAMETERS_START_EX( // Parentheses
Z_PARAM_(...), // Comma-separated
Z_PARAM_(...)
) ZEND_PARSE_PARAMETERS_END[_EX]

Errors in nested macros might be very difficult to understand :(
I would prefer not to use nested macros without a significant gain.

Not sure what you mean about errors, unless you're talking about missing a
comma or such...

And those macro calls themselves aren't really nested, just in parentheses
of course.

They are filling [multiple] structs, although that was also the case with
the version using the EXACT current syntax. :-)

Anyway though, it doesn't matter much; not sure what you'll want to do with
all the possibilities I have! And a simple script converts occurrences to
the new syntax for testing (instead of bigger patch).

Significant gain? Nope. :-) I only did that in order to use the "static"
storage specifier in one place, for a pointer to the packed rodata, instead
of filling it at runtime. But I think the file size was the same with or
without static, even though it saved instructions. So not a requirement,
just part of my experiments

Like I said, the BIG neat thing is getting the same optimization (all except
the "static" part) for the traditional ZPP. I hadn't touched it since
last message until this week (doing other stuff and too sick ~4 days to do
anything :-/) and wanted to check closer to final code before replying --
but still looks good with GCC so far!

So depending, there's maybe less interest in my smaller FAST_ZPP
implementation... shrug

Overall, the code size is reduced (vs traditional ZPP), but the file
size isn't (static stuff in rodata or whatever), which was a bit
surprising, although most of these PHP functions don't have many
parameters...

I may just guess, where this static data came from, because I didn't see
the code yet :)

Just "static const" stuff. :-) After the very first attempt, I've wanted to
pack stuff together. Function min/max args and any flags (QUIET/THROW, or
the new METHOD) are in a 4 byte int. (GCC doesn't want to pack them
together in the latest case, but easily fixed.) Then a byte for each
parameter. So, I tried "static const" to eliminate the movb instructions,
that's all.

Just to give an idea, here's the different instructions for atan2() with GCC
4.8 -O2 (after push %rbx, comments mostly for others):

== Tradtional ZPP ==
xor %eax,%eax # ??? align padding?
mov %rsi,%rbx
mov $0x61c4f3,%esi # format string ptr
sub $0x10,%rsp
mov 0x2c(%rdi),%edi # ZEND_NUM_ARGS()
lea 0x8(%rsp),%rcx # &num2
mov %rsp,%rdx # &num1
callq 595670 <zend_parse_parameters>
cmp $0xffffffff,%eax
je 4f7f4f <zif_atan2+0x3f>
movsd 0x8(%rsp),%xmm1
movsd (%rsp),%xmm0
callq 419190 atan2@plt

== My macros, "static const" version ==
mov %rsi,%rbx
mov $0x7709f8,%esi # packed static info ptr; execute_data in %rdi
sub $0x20,%rsp # 16 bytes more; each parameter needs 16 bytes stack
mov %rsp,%rdx # &num1 AND &num2, effectively; usually "lea ?,%rdx"
callq 5935d0 <zend_fast_parse_parameters>
test %eax,%eax # shorter than cmp comparing with SUCCESS vs FAILURE
jne 4f6f84 <zif_atan2+0x34>
movsd 0x10(%rsp),%xmm1
movsd (%rsp),%xmm0
callq 419330 atan2@plt

== Traditional ZPP, optimized at compile time ==
mov $0x2,%eax # ??? max_args, for below
mov %rsi,%rbx
sub $0x30,%rsp
lea 0x10(%rsp),%rdx # &num1, &num2, ..., effectively
mov %rsp,%rsi # packed info, filled by the following
movb $0x2,(%rsp) # min_args
mov %ax,0x1(%rsp) # max_args
movb $0x0,0x3(%rsp) # flags (none)
movb $0x2,0x4(%rsp) # 'd' double type: 2
movb $0x2,0x5(%rsp) # 'd' double type: 2
callq 5935f0 <zend_fast_parse_parameters>
test %eax,%eax
jne 4f6fa8 <zif_atan2+0x58>
movsd 0x20(%rsp),%xmm1
movsd 0x10(%rsp),%xmm0
callq 419330 atan2@plt

That (optimizing traditional string ZPP) will be the equivalent of 64KB+
of C code (repetition), all reduced to nothing. :-) And more of that should
(will) be packed together. Hopefully this continues, and with other
compilers, on non-Windows anyway.

Don't know about Windows now... Visual Studio 2008 and 2012 (not much
difference) are NOT optimizing away the code (other times it was GCC with
issues). :-/ Not sure why. Of course they don't support the necessary
compound literals anyway, but I was just testing a manual case... I'll have
to try and check 2015 version soon.

Regardless, there will be a fallback function to be called with optimized
runtime string parsing, to be used if compilers don't create optimized code.
I'll be checking more compilers, of course...

Sorry for the delay. Thought I'd have patch for you when you got back!
It's really about "finished" now, but not sure how many more days of final
tweaking and testing till ready for patch. :-)

Thanks. Dmitry.

Matt

The biggest size savings actually came from the simple initial
optimization of zend_parse_params_none(). Down to almost nothing, much
faster, and saved 4KB on my --disable-all builds.

NEW GOODNESS -- What would of course be nice to have is a big
optimization
of the traditional zend_parse[_method]_parameters[_ex|_throw] to avoid
changing them all. And it seems some people, like Derick, prefer it.

Of course the obvious way I first had in mind weeks ago was to simply
parse its format string faster (once-ish) at runtime, and then feed it to
this new FAST_parse function. Should give at least 2x speedup I figured.
But with this latest implementation, where the function should probably
now
be called parse_parameters_ARRAY instead of fast_parse, it would need a
second pass after parsing the string. Not a huge deal, but...

What would be really nice is to have the compiler parse the format
string, at compile time, and use the new system directly. And... that
should be possible!! 8-)

Last week I figured GCC's "statement expressions" [1] could be used,
which
most compilers seem to support, except MSVC. But just over the weekend I
realized an inline function could be used with a compound literal (for
the
varargs), which is also supported in the latest MSVC versions. Awesome!

And again, fear not, ALL the code can be completely removed by the
compiler, leaving only movb instructions instead of lea+mov/push for the
traditional ZPP function call. So, better than my initial
implementation(s), and nearly the same as my final macro version! I was
just testing prototypes of portions with GCC yesterday, which does fine
after adjusting to not generate horribly stupid code.

Now to implement it into PHP ASAP! Then I'll save a few more
banches/instructions in the parse function (specialized for common cases;
some useless GCC instructions), comment and clean up my experimental
mess,
and write up some explanation of the changes before sending patch. Oh,
and
I should verify what Clang does with the code as well...

Stay tuned!

[1] https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

9 years ago by Levi Morrison — view source

unread

Don't know about Windows now... Visual Studio 2008 and 2012 (not much
difference) are NOT optimizing away the code (other times it was GCC with
issues). :-/ Not sure why. Of course they don't support the necessary
compound literals anyway, but I was just testing a manual case... I'll have
to try and check 2015 version soon.

VS 2015 supports compound literals, I believe.

9 years ago by Matt Wilmas — view source

unread

Hi Levi,

----- Original Message -----
From: "Levi Morrison"
Sent: Thursday, August 06, 2015

Don't know about Windows now... Visual Studio 2008 and 2012 (not much
difference) are NOT optimizing away the code (other times it was GCC with
issues). :-/ Not sure why. Of course they don't support the necessary
compound literals anyway, but I was just testing a manual case... I'll
have
to try and check 2015 version soon.

VS 2015 supports compound literals, I believe.

Yes, VS 2013 added, AFAIK. But I was just talking about optimizing the code
that would use them. A compound literal (void *[]), derived from variadic
macro, is needed to transform zend_parse_parameters() into a non-varargs
inline function call (since va_arg usage prevents inlining).

The problem in the earlier VS versions, which I simulated manually without
compound literals, is that it doesn't want to optimize away all the inlined
stuff, leaving only the result. Definitely can't have something creating
several KB of extra instructions! :-)

So unless they improved something in the newest versions, this wouldn't be
able to be used there, unless I can work around it somehow. I don't know if
macros, instead of inline functions, inside the main inline function would
help or not...

Although, it would simplify a couple tiny parts if didn't need to support
MSVC... First, detecting a string literal (99% of usage): could just use
__builtin_constant_p() instead of a macro trick.

And second, using a variable length array, with size set by, well, a
variable, which I think VS still doesn't support from C99, right? (It's for
a "variable" in this case, but always the same, so should optimize like a
compile-time size.)

Thanks,
Matt

9 years ago by Pierre Joye — view source

unread

Hi Levi,

----- Original Message -----
From: "Levi Morrison"
Sent: Thursday, August 06, 2015

Don't know about Windows now... Visual Studio 2008 and 2012 (not much
difference) are NOT optimizing away the code (other times it was GCC
with
issues). :-/ Not sure why. Of course they don't support the necessary
compound literals anyway, but I was just testing a manual case... I'll
have
to try and check 2015 version soon.

VS 2015 supports compound literals, I believe.

Yes, VS 2013 added, AFAIK. But I was just talking about optimizing the
code that would use them. A compound literal (void *[]), derived from
variadic macro, is needed to transform zend_parse_parameters() into a
non-varargs inline function call (since va_arg usage prevents inlining).

The problem in the earlier VS versions, which I simulated manually
without compound literals, is that it doesn't want to optimize away all the
inlined stuff, leaving only the result. Definitely can't have something
creating several KB of extra instructions! :-)

So unless they improved something in the newest versions, this wouldn't
be able to be used there, unless I can work around it somehow. I don't
know if macros, instead of inline functions, inside the main inline
function would help or not...

Although, it would simplify a couple tiny parts if didn't need to
support MSVC... First, detecting a string literal (99% of usage): could
just use __builtin_constant_p() instead of a macro trick.

And second, using a variable length array, with size set by, well, a
variable, which I think VS still doesn't support from C99, right? (It's
for a "variable" in this case, but always the same, so should optimize like
a compile-time size.)

If you have a piece of self contained code to test it, we can then add it
to the VC test repo to valid what we can support with 7+.

9 years ago by Matt Wilmas — view source

unread

Hi Pierre,

----- Original Message -----
From: "Pierre Joye"
Sent: Thursday, August 06, 2015

Hi Levi,

----- Original Message -----
From: "Levi Morrison"
Sent: Thursday, August 06, 2015

Don't know about Windows now... Visual Studio 2008 and 2012 (not much
difference) are NOT optimizing away the code (other times it was GCC
with
issues). :-/ Not sure why. Of course they don't support the necessary
compound literals anyway, but I was just testing a manual case... I'll
have
to try and check 2015 version soon.

VS 2015 supports compound literals, I believe.

Yes, VS 2013 added, AFAIK. But I was just talking about optimizing the
code that would use them. A compound literal (void *[]), derived from
variadic macro, is needed to transform zend_parse_parameters() into a
non-varargs inline function call (since va_arg usage prevents inlining).

The problem in the earlier VS versions, which I simulated manually
without compound literals, is that it doesn't want to optimize away all
the
inlined stuff, leaving only the result. Definitely can't have something
creating several KB of extra instructions! :-)

So unless they improved something in the newest versions, this wouldn't
be able to be used there, unless I can work around it somehow. I don't
know if macros, instead of inline functions, inside the main inline
function would help or not...

Although, it would simplify a couple tiny parts if didn't need to
support MSVC... First, detecting a string literal (99% of usage): could
just use __builtin_constant_p() instead of a macro trick.

And second, using a variable length array, with size set by, well, a
variable, which I think VS still doesn't support from C99, right? (It's
for a "variable" in this case, but always the same, so should optimize
like
a compile-time size.)

If you have a piece of self contained code to test it, we can then add it
to the VC test repo to valid what we can support with 7+.

Sure! Simply:

size_t num = 4;
char foo[num];

I wondered about emulating with _alloca(), but a quick check (in 2008!)
shows that it doesn't optimize it out even with a true constant value...

Matt

9 years ago by Matt Wilmas — view source

unread

Hi Dmitry, all,

Things are looking really good now, f-i-n-a-l-l-y! Last weekend, after
thinking "no more changes" again, I thought of a couple more improvements,
hah, and now I think there isn't much that could be improved.

So it should be fully alive this weekend, flying, with the fastest/smallest
parameter parsing we could imagine, across all of PHP! I guess that means
start looking for it next week...? :-) I may just send a patch sooner
without even writing up an explanation about parts first like I planned.

More below...

----- Original Message -----
From: "Matt Wilmas"
Sent: Wednesday, August 05, 2015

Hi Dmitry,

[...]

Unfortunately (only because I said "same macro syntax," but no big
deal),
the syntax had to be changed, from:

ZEND_PARSE_PARAMETERS_START_EX
Z_PARAM_(...)
Z_PARAM_(...)
ZEND_PARSE_PARAMETERS_END[_EX]

to

ZEND_PARSE_PARAMETERS_START_EX( // Parentheses
Z_PARAM_(...), // Comma-separated
Z_PARAM_(...)
) ZEND_PARSE_PARAMETERS_END[_EX]

Errors in nested macros might be very difficult to understand :(
I would prefer not to use nested macros without a significant gain.

[...]

Anyway though, it doesn't matter much; not sure what you'll want to do
with all the possibilities I have! And a simple script converts
occurrences to the new syntax for testing (instead of bigger patch).

Significant gain? Nope. :-) I only did that in order to use the "static"
storage specifier in one place, for a pointer to the packed rodata,
instead of filling it at runtime. But I think the file size was the same
with or without static, even though it saved instructions. So not a
requirement, just part of my experiments

I was wrong about this; there is "significant gain." Few days after last
message, I couldn't even figure out my own code, haha, trying to remember
what I tried, when. Anyway, the macro change was NOT to try the "static"
specifier (came later), but is the basis for the compiler "magic" that
allows the &dest vars to never be referenced -- e.g. no lea, etc. for
function. So the minor macro change is important.

Like I said, the BIG neat thing is getting the same optimization (all
except the "static" part) for the traditional ZPP. I hadn't touched it
since last message until this week (doing other stuff and too sick ~4 days
to do anything :-/) and wanted to check closer to final code before
replying -- but still looks good with GCC so far!

Clang 3.4 is also generating perfect code for compile-time parsing of
traditional ZPP's format string. I'll monitor it and GCC closely as final
changes are made. I haven't tried older versions yet to see if there's a
minimum version to get compile-time transformation.

BTW, I wondered about zpp's "num_args" param -- assumed it was always
equal to ZEND_NUM_ARGS(), until I saw some instances with a fixed literal
number. Oops! Luckily, the "check" can be optimized out in all but one
case AFAICT with GCC. And all but a handful of other cases (in pgsql.c)
with Clang.

So depending, there's maybe less interest in my smaller FAST_ZPP
implementation... shrug

Nevermind that comment...

Weeks ago, I thought it might be desired to not give up inlining in all
cases to get small code. So I thought about a "hybrid" system where the
smallest code could be inlined for the simplest cases (when function
call would have highest % overhead), otherwise call the function. That's in
the process of being finished now, with some settings (#define's) to control
amount of inlining (or none). I'm hoping the compilers will again remove
everything but the few necessary instructions without me having to make
explicit checks...

[...]
sub $0x20,%rsp # 16 bytes more; each parameter needs 16 bytes stack

I realized that the stack space could easily be reduced to 8 bytes per &dest
var, instead of 16/param... Doesn't really matter I guess, but now on
64-bit, stack space is same as normal &dest vars, except zend_bools.
(Compiler effectively removes all dest vars. :^))

[...]
That (optimizing traditional string ZPP) will be the equivalent of 64KB+
of C code (repetition), all reduced to nothing. :-) And more of that
should (will) be packed together. Hopefully this continues, and with
other compilers, on non-Windows anyway.

Don't know about Windows now... Visual Studio 2008 and 2012 (not much
difference) are NOT optimizing away the code (other times it was GCC with
issues). :-/ Not sure why. Of course they don't support the necessary
compound literals anyway, but I was just testing a manual case... I'll
have to try and check 2015 version soon.

Nope, VS 2015 still won't optimize away any of it, it seems. So looks like
no compile-time transformation of traditional zpp on Windows...

Regardless, there will be a fallback function to be called with optimized
runtime string parsing, to be used if compilers don't create optimized
code. I'll be checking more compilers, of course...

For the sake of Windows (or any other fallbacks), I really wanted to
optimize zpp well for runtime string parsing. After overthinking it, it's
fairly simple, and what could've been there all along. What we should wind
up with is traditional zpp that's as good as the "fast parsing" function,
except: 1) lea, etc. for vars at call site, and 2) the string has to be
looked at ONCE, instead of 6-7 times now. :-O

Matt

10 years ago by Yasuo Ohgaki — view source

unread

Hi Ferenc,

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?

I'm curious about the status of Fast ZPP and it's usage.
The RFC says it reduces function call overheads by 90% and
I didn't see reason why we shouldn't move to Fast ZPP.

"For some really simple function like is_string() or ord() the overhead of
zend_parse_parameters() may be about 90%."
https://wiki.php.net/rfc/fast_zpp

I'll use it for functions called many times.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Ferenc Kovacs — view source

unread

Hi Ferenc,

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?

I'm curious about the status of Fast ZPP and it's usage.
The RFC says it reduces function call overheads by 90% and
I didn't see reason why we shouldn't move to Fast ZPP.

"For some really simple function like is_string() or ord() the overhead of
zend_parse_parameters() may be about 90%."
https://wiki.php.net/rfc/fast_zpp

I'll use it for functions called many times.

I wouldn't consider the likes of pg_fetch_* to be appropriate for for using
Fast ZPP, even db heavy applications are unlikely to call it more than a
houndred times per request, so the perf gain would be negligible compared
to the increased cost of maintenance.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

10 years ago by Yasuo Ohgaki — view source

unread

Hi Ferenc,

Hi Ferenc,

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?

I'm curious about the status of Fast ZPP and it's usage.
The RFC says it reduces function call overheads by 90% and
I didn't see reason why we shouldn't move to Fast ZPP.

"For some really simple function like is_string() or ord() the overhead
of zend_parse_parameters() may be about 90%."
https://wiki.php.net/rfc/fast_zpp

I'll use it for functions called many times.

I wouldn't consider the likes of pg_fetch_* to be appropriate for for
using Fast ZPP, even db heavy applications are unlikely to call it more
than a houndred times per request, so the perf gain would be negligible
compared to the increased cost of maintenance.

I agree. It's painful to maintain
#ifndef FAST_ZPP
zend_parse_parameter();
#else
Fast ZPP
#endif
I'll just leave them alone until #ifndef is not required.

Thanks.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Levi Morrison — view source

unread

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 +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.

9 years ago by Matt Wilmas — view source

unread

Hi Levi,

----- Original Message -----
From: "Levi Morrison"
Sent: Wednesday, June 24, 2015

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 +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