[RFC] Fast Parameter Parsing API

This patch is connected with Zend only in a way, that I worked on it during
last days (it's even not my idea).
but once I saw the idea I saw how it may be useful. I really don't
understand you attitude to us.
We are working hard to make a real big step forward...

2.5% speedup on real-life is not a good gain? where do you live? :)

Thanks. Dmitry.

Hi Dmitry, Bob,

On Fri, May 23, 2014 at 3:28 PM, Johannes Schlüter
johannes@schlueters.de 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 feel the same way. I very much the idea of rewamping zpp, it is a
long due taks.

However the way it is implemented in this RFC is not something I would
like to work with for a decade or so. The performance gain is also not
sufficient enough to justify it.

I think we should think more about other options (no matter how long
you spent discussing options before posting this RFC). I am sure we
can come with other solutions which may be cleaner and also provide
some performance improvements.

If we break APIs anyways: Can't we go for C++ which allows providing
high level APIs with high performance ...

Yes, C++ would in this case provides almost all we need for
implementing parameter management in a clean and efficient way. Not
sure if it is desired tho'.

By the way, please do not ask me to come with code and cases to valid
my comment here, I won't. At least not until things get clarified
about we wish. The last thing we need is yet another Zend vs World
about that :)

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

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.

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

Hey Dmitry!

I would be glad to see proposals from Hannes and Johannes, but we also need
to move phpng forward, and I wouldn't like to spend on this too much time.

Our proposal is mainly about speed (as well as the main phpng goal).
We identified yet another bottleneck and eliminated it.
Changes in readability and compile-time type checking are side effects of
implementation.

Oh well... while I pretty much appreciate the efforts put into phpng,
Zend isn't all too popular for designing usable APIs... because it
often happens in a rush. Let me recall you that this list is often
about politics nowadays, and from a political POV this statement just
costed 20% of yay-votes.

Well, politics are one part of the problem and I agree that we see
that too often.

However what I see now is partially what I have seen back to php4 > 5
move. We are deciding now what we will use for a decade+ after the
release of php6. And as much as I like to get a faster PHP, I am
really looking forward (and do it) an API cleanup and other deeper
change to ease:

• core maintenance
• easier, well documented, exposed APIs for 3rd party developers (extensions)

It is no secret that our internals APIs are bad. PHP-CPP success
despite its current limitation or stability is yet another sign. I
have been working on Ruby, Go or Python internals lately, we have a
long road to achieve only part of the simplicity we can see there.
This is something I would like to put more efforts, first, prior to
push even more hacks to gain 1-2% (even if 10x 1% means 10%
performance increase). It is always easier to optimize a clean,
smaller code base, with less warnings, aliases, etc. than what we
actually have now.It is getting worst now because of partial changes
in many areas, simply because "it makes php faster if we change this
specific function".

I hope I do not make my point unclear, I appreciate a lot the
performance improvements Nikita, Laruence, Bob and Dmitry are working
on, this is very promising. However I would really like to focus on
global design, clean code base and as much as possible warning free as
well, this will make everyone work much easier for the next 10-12
years.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

To be perfectly honest, I tend to agree that the readability issues with
this proposal make it a bit difficult to digest. And I'm not taking a 2.5%
real world performance gain lightly - it's huge.

I think we need to consider other alternatives as code readability and
maintainability are important factors to consider, not just performance...

Merci! It is a pleasure to read that from you, I really mean it :-)

--
Pierre

@pierrejoye | http://www.libgd.org

I personally see it more readable than "sZ|l", but of course, other people
may think differently.
I would be glad if someone would propose something useful in reasonable
time.

Thanks. Dmitry.

To be perfectly honest, I tend to agree that the readability issues with
this proposal make it a bit difficult to digest. And I'm not taking a 2.5%
real world performance gain lightly - it's huge.

I think we need to consider other alternatives as code readability and
maintainability are important factors to consider, not just performance...

Zeev

I would be glad to see proposals from Hannes and Johannes, but we also
need to move phpng forward, and I wouldn't like to spend on this too much
time.

Our proposal is mainly about speed (as well as the main phpng goal).
We identified yet another bottleneck and eliminated it.
Changes in readability and compile-time type checking are side effects of
implementation.

Thanks. Dmitry.

Hey:

Please take a look at https://wiki.php.net/rfc/fast_zpp

 It's really a great improvement.

 zend_parse_parameters is too heavy,  and to me:

 Z_PARAM_STR()  is obviously readable than

zend_parse_parameter("s" /* what the hell s means here? */,)

 and the performance gain is also very significant ..

 actually, I thought about somethings like that.. but this patch

is better...

 and these new APIs didn't break any APIS,   just provides a more

fast choice...

 I really don't understand why you guys think it not good?

thanks

Thanks. Dmitry.

--
Xinchen Hui Laruence
Consultant at Zend
http://www.laruence.com/