> -----Original Message----- > From: Christopher Jones [mailto:christopher.jo...@oracle.com] > Sent: Thursday, February 14, 2013 9:25 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] 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.
That depends on whether there'll be apparent consensus about it; But it can wait until after that RFC is approved, as a separate discussion and if needed a separate vote. > > 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.) I think it goes beyond of the scope of the RFC but I'll add a bit of blurb there. > >> - 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. OK. > >> 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...) I actually think that the differences between the 'safe' and 'extreme' settings don't correspond too well to development vs. production. They depend on the nature of the code/app you're running, and not on whether you're developing the code or running it in production. In my opinion, the defaults should be more or less the defaults we have today, perhaps with minor tweaks - but with the guiding principle being that they need to be *safe*, and minimize the chance that semantics would change if you enable/disable O+. The 'recommended' settings, which should really read 'extreme performance settings', should end up in a documentation section, with nice clear warnings about each and every setting and its potential impact on how apps will perform. I'll clarify that in the RFC. > >> - 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 > > O+ 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. Agreed. Rasmus and I ping ponged some names and we may want to go with something more generic along the lines of 'OpCache'. It's shorter than the "zend_optimizerplus." prefix we currently have for INI directives; It has the strong implication that it's mostly about caching opcodes; And we could also mention that 'Op' also originates in the Optimizer Plus component this was based on. I suggest that we decouple the decision on naming from the decision on inclusion; There's clear agreement on my part that we can name it differently from 'Zend Optimizer+' so it'd be just a matter of finding a name everyone (or a majority at least) of people are happy with. Updated RFC: https://wiki.php.net/rfc/optimizerplus Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
