Re: phpng: Refactored PHP Engine with Big Performance Improvement

From: Date: Tue, 06 May 2014 04:19:52 +0000
Subject: Re: phpng: Refactored PHP Engine with Big Performance Improvement
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-73930@lists.php.net to get a copy of this message
On Tue, May 6, 2014 at 1:44 AM, Dmitry Stogov <dmitry@zend.com> wrote: > ZTS wasn't in our priority list, but Nikita made it more or less work. Why do I have a deja vu feeling? ;) >> Also one thing is totally missing, and is also caused by something >> that becomes a common case, the 64bit support as it should be has been >> totally ignored. That makes Anatol work to keep the 64bit branch >> almost useless. My take on it is that we should either: >> >> >> - move your patch to this branch and then merge to master >> - merge the 64bit branche then this patch > > > I afraid both ways aren't going to be simple. Rght, but again, I really do not feel comfortable to ask Anatal or my team to redo all the work. This would be very bad. > Anyway, I think 64-bit integer support on Windows64 makes full sense and > it's possible to add it into "phpng" right now. Again, it is by far not only a windows change, even if Windows is the platform with the most visible change from a user point of view. > I'm not so sure about size_t string length. It is hardly imaginable to release php 6 with strings length still using integer. The memory consumption has been shown to be minimal during the discussions about the 64bit support. Or did I miss some important new information? > I understand your opinion, but when we started this project we didn't know > if we will get any useful results at all. > You know, I can't ask everyone in PHP community to freeze development and > wait while we are thinking :) No, but it is possible to get a branch and work on it, sync it with the other relevant branch. That is what we have done for the 64bit branch, providing updated builds and tests results while working on it. Everyone can test it or contribute. This is the way to do such things from a technical point of view. It is also the way to do it from a cooperation point of view, for the reasons I gave earlier. >> I am not sure how to change that or make developers being more open >> and stopped hidden developments. Any ideas or thoughts on this topic >> are welcome. It is critical and vital for php, a must do. > > > I don't see problem in hidden development. The formed ideas come as RFC with > patches. Well, I do when it comes to such massive changes, no matter how positive they are. It is all about being open and transparent. Early participation eases the understanding of the changes, design or debugging of the new features or changes. This reduces the bus factor when it comes to maintain it and we both know that this has been an issue for too long for everything around the engine area. Cheers, -- Pierre @pierrejoye | http://www.libgd.org

« previous php.internals (#73930) next »