Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65844
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 141.146.126.69 as permitted sender)
Message-ID: <511D2825.8000304@oracle.com>
Date: Thu, 14 Feb 2013 10:08:37 -0800
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
References: <e8aaa4ce59a801e53c6abc9d287d1859@mail.gmail.com> <511BFC81.8020400@oracle.com> <7de2703f77537a47b457c4479a19ac3a@mail.gmail.com> <CAF+90c9ftPKjAyH3QJuGLEqu=JP26h0wZPAs6tfF4tq90CNLtQ@mail.gmail.com>
In-Reply-To: <CAF+90c9ftPKjAyH3QJuGLEqu=JP26h0wZPAs6tfF4tq90CNLtQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available
From: christopher.jones@oracle.com (Christopher Jones)



On 02/14/2013 08:02 AM, Nikita Popov wrote:
> On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski <zeev@zend.com <mailto: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).

This raises questions for Zeev to address.

>
> Btw, I was quite surprised to see the block optimizations in O+ :) Really cool!
>
> Nikita

The php.ini parameters will likely need a name (or two - if the optimizer is distinct from the op-code cache) as a prefix.

Chris

-- 
christopher.jones@oracle.com  http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html