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. > >> >> 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 Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
