Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65836
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c9ftPKjAyH3QJuGLEqu=JP26h0wZPAs6tfF4tq90CNLtQ@mail.gmail.com>
References: <e8aaa4ce59a801e53c6abc9d287d1859@mail.gmail.com>
	<511BFC81.8020400@oracle.com>
	<7de2703f77537a47b457c4479a19ac3a@mail.gmail.com>
	<CAF+90c9ftPKjAyH3QJuGLEqu=JP26h0wZPAs6tfF4tq90CNLtQ@mail.gmail.com>
Date: Thu, 14 Feb 2013 09:11:42 -0700
Message-ID: <CAFMT4NqM05VgqYEGkkx=JMjPX2mj3hbpCJiBvBn2_emiRahkxQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, Christopher Jones <christopher.jones@oracle.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available
From: morrison.levi@gmail.com (Levi Morrison)

On Thu, Feb 14, 2013 at 9:02 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> 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).

I usually don't chime in with 'me too' comments, but I think Nikita
summed it up nicely.