On Mon, Jul 21, 2014 at 2:24 PM, Julien Pauli <jpa...@php.net> wrote:
> On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > Hi Julien, > > > >> > >> Hi > >> > >> I can only agree here. > >> > >> I'd like a clean API. We need to consider PHP-Next jump as an > opportunity > >> to > >> clean our API and finally have something understandable for a > >> newcomer, and documented. That's a move nobody dared to take in the > >> last decade, degrading more and more our codebase in term of > >> understandability and flexibility. This can't last > > > > > > I'm more than agree about internal cleanup. > > phpng benchmark results proved that we take the right direction and now > we > > implemented most the ideas we had. > > Note that we tried not to change PHP behaviour in any way. > > Now it's a good time to start the cleanup work. > > Not changing behavior is nice and very hard work to do, so congrats on > that one. > > If cleaning the API receives "no-go" because the cleanups would > involve swaping some parameters in functions, or turning macros to > inline functions , which drops some little percentage in performance > on some rare compilers, then there will be a problem to me. > > We need a trade-off here. We can't leave unreadable code in, should > this code be written in a specific way for performances. We can afford > a little 1% or 2 IMO. > 1-2% is not a huge step back :) but in case of few such steps we may discard a lot. > > > > >> > >> Old features and unused things should be cleaned up. > >> Quickly caught, impacting the engine : > >> - Resources are a hell, mixed with zend_lists etc... inconsitstent and > >> absolutely PITA to develop with. > >> - Streams need to be cleaned up and reworked to support full > >> asynchronous IOs, which could involve threads, thus engine tied > >> - Signals have been worked on starting with 5.4 (AFAIR), but never > >> activated by default. I guess the actual implementation lacks a bit > >> more reflection to be stable, and to finally propose signal managers > >> into userland. ext/pcntl should be somehow merged to core, and this as > >> well would involve engine work > >> - TSRM need to find love, or to find a better replacement, which would > >> involve a big engine work as well > >> - ... and so on > > > > > > Some of the topics above are really big... :) > > > >> > >> > >> Macro hell should be reworked as inlined functions, and I'd like we > >> start supporting C99 as well. > >> > >> Performance is a userland point. > >> API, doc, and clean things are developers points, and IMO, they are as > >> important. > >> > >> What about merging OPCache to the branch ? > >> This was talked about at PHP5.5 release, has never happened yet, and > >> doesn't seem planed. This could have a big impact on the engine > >> codebase. > > > > > > What do you mean? isn't it already there. > > I'm also going to remove opcache code for old PHP versions in php-next. > > I was talking about merging the code bases. > For example, shared memory model from OPCache could be merged into > Zend/ and expose an API one could reuse in extensions needing SHM. > Also, accelerator's code could be merged into Zend/zend_execute and > Zend/ZendVM > We thought about it many time, but didn't have time to do it. Thanks. Dmitry. > > Julien >
