Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65835
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7de2703f77537a47b457c4479a19ac3a@mail.gmail.com>
References: <e8aaa4ce59a801e53c6abc9d287d1859@mail.gmail.com>
	<511BFC81.8020400@oracle.com>
	<7de2703f77537a47b457c4479a19ac3a@mail.gmail.com>
Date: Thu, 14 Feb 2013 17:02:17 +0100
Message-ID: <CAF+90c9ftPKjAyH3QJuGLEqu=JP26h0wZPAs6tfF4tq90CNLtQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Christopher Jones <christopher.jones@oracle.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442876813261304d5b162de
Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d0442876813261304d5b162de
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski <zeev@zend.com> wrote:

> >   - Should the name reflect the code's main purpose (op-code caching),
> >     and allowing a future use of "optimizer" for a more sophisticated
> >     optimizer implementation?  Or do you see Optimizer+ being the
> >     framework for such optimizations?
>
> O+ does perform some optimizations in addition to caching code, in a pretty
> sophisticated manner actually (block optimizations).  Optimizations - which
> can be expensive to carry out - are definitely a good fit with an opcode
> cache, that ensures that you wouldn't have to do these optimizations more
> than once.  I'm obviously subjective but I think the name Optimizer+ does a
> good job at suggesting that it's both an Optimizer but also something else.
> Perhaps we should call it OptiCache? :)
>

If this will go into PECL first then I see no reason to change the name
from Optimizer+. If this will go into PHP then it shouldn't need a name at
all, should it? It could just be "opcode cache" (--enable-opcode-cache /
--disable-opcode-cache). That seems more descriptive to me then some fancy
name like "Optimizer+". Regarding the optimizations it contains, imho those
are a separate concern and if Optimizer+ goes into core both aspects should
be cleanly separated (and you should be able to enable/disable them
separately). The optimizations are not directly related to caching. Caching
makes them more viable for web requests, but as someone already pointed out
the optimizations are also useful on CLI, where compile times just aren't a
concern anyway (but run times can be).

Btw, I was quite surprised to see the block optimizations in O+ :) Really
cool!

Nikita

--f46d0442876813261304d5b162de--