Re: Zend Optimizer+ Source Code now available

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