Re: Re: [RFC] Fast Parameter Parsing API
| From: | Pierre Joye | Date: | Mon, 26 May 2014 07:07:39 +0000 |
| Subject: | Re: Re: [RFC] Fast Parameter Parsing API | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-74479@lists.php.net to get a copy of this message | ||
On Mon, May 26, 2014 at 8:25 AM, Michael Wallner <mike@php.net> wrote:
> Hey Dmitry!
>
> On 26 May 2014 07:39, Dmitry Stogov <dmitry@zend.com> wrote:
>> 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