Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75767
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.177 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CA+9eiLs3=5CF=KO7Fi28L1S1R833ZGXf0Wfr9gRZO6mCYzRamQ@mail.gmail.com>
References: <b39ebab3d19d76cda9bafa25919c0e67@mail.gmail.com>
 <CAEZPtU52X737iUZgKUJbT0bb9z-cr_EYfxMcmv804AhnTpLnhg@mail.gmail.com>
 <CAMUwpuQrQd-ROPN0oRk37+U1JFnz487__vZxGjSC5f-TcYyfqg@mail.gmail.com> <CA+9eiLs3=5CF=KO7Fi28L1S1R833ZGXf0Wfr9gRZO6mCYzRamQ@mail.gmail.com>
Date: Mon, 21 Jul 2014 12:24:30 +0200
Message-ID: <CAMUwpuRO24zdhPJwYQuxfN9ot1f+7KrQZkhGzcgBVjrgs0My8A@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: Move phpng to master
From: jpauli@php.net (Julien Pauli)

On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov <dmitry@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