On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov wrote:
Hi Julien,

I can only agree here.

I'd like a clean API. We need to consider PHP-Next jump as an opportunity
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

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

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


Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase