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.jo...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
