Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75777
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuRO24zdhPJwYQuxfN9ot1f+7KrQZkhGzcgBVjrgs0My8A@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>
	<CAMUwpuRO24zdhPJwYQuxfN9ot1f+7KrQZkhGzcgBVjrgs0My8A@mail.gmail.com>
Date: Mon, 21 Jul 2014 14:50:25 +0400
Message-ID: <CA+9eiLskJrdVt_2npOXek2YfZncDqiCBzV-GdrxD_EBv5M_kgQ@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Pierre Joye <pierre.php@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11339e88e5cc5a04feb1df9b
Subject: Re: [PHP-DEV] RFC: Move phpng to master
From: dmitry@zend.com (Dmitry Stogov)

--001a11339e88e5cc5a04feb1df9b
Content-Type: text/plain; charset=UTF-8

On Mon, Jul 21, 2014 at 2:24 PM, Julien Pauli <jpauli@php.net> wrote:

> 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.
>

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
>

--001a11339e88e5cc5a04feb1df9b--