On Thu, Feb 14, 2013 at 9:02 AM, Nikita Popov <nikita....@gmail.com> wrote: > > On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski <z...@zend.com> wrote: > > > > - 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? :) > > > > If this will go into PECL first then I see no reason to change the name > from Optimizer+. If this will go into PHP then it shouldn't need a name at > all, should it? It could just be "opcode cache" (--enable-opcode-cache / > --disable-opcode-cache). That seems more descriptive to me then some fancy > name like "Optimizer+". Regarding the optimizations it contains, imho those > are a separate concern and if Optimizer+ goes into core both aspects should > be cleanly separated (and you should be able to enable/disable them > separately). The optimizations are not directly related to caching. Caching > makes them more viable for web requests, but as someone already pointed out > the optimizations are also useful on CLI, where compile times just aren't a > concern anyway (but run times can be).
I usually don't chime in with 'me too' comments, but I think Nikita summed it up nicely. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
