Re: Re: 64bit and phpng, votes and plans

On Wed, May 21, 2014 at 12:47 PM, Zeev Suraski <zeev@zend.com> wrote: > Last, there’s nothing slippery about *thinking about performance*.. We > should always think about performance with whatever we do. Much like > consistency or security, performance isn’t the one and only factor and > should be weighed against other factors, but it must be on the discussion > table on each and every thing we do. Also, performance is not at all > inherently contradictory to consistency, security or even code quality. > PHP 5.6 is almost twice as fast as PHP 5.0, and I’d argue the codebase is > better and just as secure and consistent if not more. phpng is another > textbook example of how we (aka Dmitry, Xinchen and Nikita) managed to get > 10-30% gains in real world performance without reducing the quality of the > code in any way, and arguably – making it better. All this 100%+ > performance gains between 5.0 and phpng is tedious, extremely complex work, > where individual changes rarely result in a boost of more than 3-5%. You > can imagine how much work it is to get to 100%+ improvements, and you > should therefore imagine why we don’t take lightly a change that will undo > some of these gains unless we reach the conclusion they’re truly justified, > as opposed to just being a matter of principle, or even being interesting > in rare uncommon cases. What you totally forget to mention: - we cannot refactor the core in a stable branch, not even using (much) better types remember? That's why you rejected and argued very hard against the 64bit RFC for 5.6, saying that it is all good for next (we can happily see the reasoning now...) - The next major version is a 2+ years effort. What does it mean? . open doors for deeper work and redesign than what we have done in the last decade . consistency and long due internals APIs and implementations cleanup is possible Now, one can still argue that it is still possible with phpng. But given the amount of changes brought by phpng, I have to say that the method used to implement it is by far not optimal. It not only causes a total freeze of any improvement (features or APIs) in the core until it reaches an alpha state, but it will also double the amount of work necessary to finalize it. A little cleanup of the core would have reduced the amount of work necessary to actually implement the ideas behind phpng, even more once you have seen that they are working well and are more than promising. This kind of things could have been avoided or done faster if Zend would have been more open about its current work. And one day, I will understand why NDAs and all this crap are necessary to work on php. Or maybe not. All in all it is bad for the php project (again, the project, not the results of what is being done), no matter the outcome of this patch. -- Pierre @pierrejoye | http://www.libgd.org