Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65847
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 156.151.31.81 as permitted sender)
Message-ID: <511D39EF.5060409@oracle.com>
Date: Thu, 14 Feb 2013 11:24:31 -0800
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Zeev Suraski <zeev@zend.com>
CC: PHP internals <internals@lists.php.net>
References: <e8aaa4ce59a801e53c6abc9d287d1859@mail.gmail.com> <511BFC81.8020400@oracle.com> <7de2703f77537a47b457c4479a19ac3a@mail.gmail.com>
In-Reply-To: <7de2703f77537a47b457c4479a19ac3a@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; 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 07:21 AM, Zeev Suraski wrote:
>> Great to see.
>>
>> The README covers much of the content (and in more detail) that I
>> previously
>> wanted to see in the RFC.
>
> Excellent!
>
>> There are some things still missing from the RFC, though:
>>
>>    - do you see Optimizer+ being enabled (if not in PECL) or disabled by
>>      default, etc.
>
> I *think* we should strive to have it enabled by default, but it should
> definitely be possible to turn it off too.  I guess that can be another
> voting possibility - bundle & turn on by default (vs. just bundle).

To avoid too many voting choices, I think this can be decided outside
the RFC process.

>
>>    - your email comment to John Carter about Zend Guard decoder
>
> We don't want to create any special cases in O+;  We would either take care
> of integrating it by having slightly patching our O+ build, or we'd add
> generalized facilities to O+ that will allow the loader to interact with it
> directly (that would not be unique to the Zend loader but could be used by
> any extension).  From my point of view, it's nice-to-have to solve it before
> 5.5.0, not a must-have.

This should still be stated in the RFC.  (The PHP community suffers
from poor RFCs.  Since you are a leader in the PHP community, your RFC
should set a good example.)

>
>>    - There are still open questions in the RFC; these need to be closed
>>      before voting.
>
> I think the only open question is integration with other modules, most
> notably debuggers.  This is something we'd like to tackle sooner rather than
> later, and I think it'll be easier to just go ahead and do that now that the
> source code is available.  Any other open questions that need
> answering?

I think this should be reworded before the vote occurs.  I'm fine with
leaving it under a heading "for future investigation", i.e. stating it
won't happen in an initial release.

>> Comments:
>>
>>    - The README gives recommended parameters.  Taking that advice at
>>      face value, I think these should be default settings.
>
> The default settings are designed to minimize the chance that an app or a
> workflow - which worked fine w/o O+ - will suddenly fail after O+ is
> installed.  The 'recommended' settings are for max-performance.  You can
> view it like 'Safe' vs. 'Extreme' settings.  Personally I think the default
> settings should be closer to the Safe ones...

We can probably meet in the middle: leave the hard coded defaults as
they currently are, and use those values in the php.ini-development
examples.  Php.ini-production can have the values recommended in the
README.  (Giving the proposed php.ini settings is another thing the
RFC should have...)

>>    - 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? :)

It seems a good time to disambiguate its relationship to any current
or future Zend product.

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