> -----Original Message----- > From: Christopher Jones [mailto:christopher.jo...@oracle.com] > Sent: Saturday, February 16, 2013 12:54 AM > To: Zeev Suraski > Cc: PHP internals > Subject: RE: [PHP-DEV] Zend Optimizer+ Source Code now available > > > > Hi Zeev, > > I think people are keen to see Optimizer+ merged. Hopefully the RFC can > set > expectations clear on what the short-term steps will be, and what the > bigger > picture might look like. The middle-term tasks will then work themselves > out as > we get to them (in true PHP fashion) > > - What does "Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for > it" mean? Does it mean: > > * Work really had to get it into PHP 5.5.0 with no delay to 5.5? > * Include it in /ext "as-is", i.e. perhaps no ZTS support, or marked > EXPERIMENTAL? > * Include it in PHP 5.5.x where x > 0, when Optimizer+ is complete? > > The slippage of 5.5 is an issue to some people, so clarity here > would be good.
It's in the context of this, one paragraph above it: "The question on the table is whether most users would prefer a slightly later release with an out-of-the-box working opcode cache, or a slightly earlier release without a compatible opcode cache available for several additional months." In other words, this option mean that if we can't integrate it without delaying 5.5.0, we don't integrate it. By integration I refer to including something that is production quality, potentially enabled-by-default (TBD), that everyone should feel comfortable using. > I believe the wider community is expecting the op-code cache to > "just work", so if that's not the case, the RFC should communicate > this clearly. There's also the potential to damage Zend's > reputation if what is released doesn't work well. I agree, although an opcode cache does add an extra layer of complexity, so it does stand the chance to break otherwise working setups (the same can happen with other opcode caches). It should be a rare occurrence, with the performance advantage far outweighing it. > - What are your general thoughts about its integration architecture > and the potential for alternative op-code caches to be used? I know > code can always be changed, but what (if any) design will happen > from the start to make this easy? I'm not sure. The level of integration we're talking about for 5.5.0, due to the haste, is not going to be beyond a mostly soft-bundle, at most something that gets enabled by default - but can still be disabled or outright removed. That means that you should be able to replace it with any other opcode cache you might want. However, for the future, there *might* be potential for further gains we might be able to get from tighter integration between the different layers. At this point I don't have any concrete ideas, though, so it's possible it's only theoretical. Regardless, such tighter integration - that would preclude other opcode caches from being used - will have to be the subject of a separate RFC & vote. I'll clarify that point too in the RFC. > - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Interesting names, I'm curious about pronunciation :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
