> 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). > - 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. > - 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? > 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... > - 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? :) > Questions (I haven't dug through the code): > > - What do CLI processes share? IIRC nothing, presently it's not very useful for CLI except for testing (it'll only apply to a single run). I could be wrong though, Dmitry? > - Is there an architectural reason why the 'embed' embedded SAPI > couldn't be supported? (Lack of parent forking??) As long as we can map the shared memory piece to the same base address, there's no inherent reason why we couldn't make it work with SAPI/embed. That's how we work on Windows where there's no concept of fork(); We could apply a similar concept on Linux - although note that it's not 100% reliable, a base address that's free in one process may not be available in another... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
