Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84183
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABBJUpd8f8ApcPqJp6d5ih0Bywkk4LUnFdQOD=ovL1U6nhid0Q@mail.gmail.com>
References: <CABBJUpd8f8ApcPqJp6d5ih0Bywkk4LUnFdQOD=ovL1U6nhid0Q@mail.gmail.com>
Date: Mon, 2 Mar 2015 12:33:11 -0800
Message-ID: <CAEZPtU4VOA-W9QDd6SPSDoyLNy5R8zinsPOQSLS3PAUsjwB2fw@mail.gmail.com>
To: =?UTF-8?B?5oOg5paw5a64?= <laruence@gmail.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, Dmitry Stogov <dmitry@zend.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122eb9c724be40510542039
Subject: Re: [PHP-DEV] About optimization for compiler
From: pierre.php@gmail.com (Pierre Joye)

--089e0122eb9c724be40510542039
Content-Type: text/plain; charset=UTF-8

On Feb 27, 2015 5:23 PM, "Xinchen Hui" <laruence@gmail.com> wrote:
>
> Hey Internals:
>
>       I was looking Bob's switch optimization..
>
>       then I start to worry about where is the place optimization should
goes..
>
>       in generally, PHP is a  interpreted language. IMO, it should
> compiler the PHP codes to opcode without any optimization(of course,
> we did some, but they won't change a lots of opcodes which should be
> generated)..
>
>       and, since 5.5, we already have opcache bundled in..
>
>       thus, I am proposing a principle, that is:
>
>       in the future, we only do optimization in opcache side, and keep
> Zend Compiler without any optimization... considering Zend Compiler do
> things in -O0.
>
>       since, optimization always are dangerous.. if we only do them in
> opcache, user can still run them codes with disable opcache, or at
> least disable some optimization level which cause that..
>
>       what do you think?

As it sounds appealing, I am not a big fan of creating different scenarios
from a core perspective.

It will make the testing and maintenance harder, by  introducing extra
possible bugs.

If I am not mistaken, it was planed to have to integrate opcache in the
engine, making it part of it instead than a still optional extension. That
would be a better way and may open new possibilities.

--089e0122eb9c724be40510542039--