Re: Re: [RFC] Fast Parameter Parsing API

From: 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

« previous php.internals (#74479) next »