Re: [RFC] Integrating Zend Optimizer+ into the PHP distribution

On 30/01/13 00:54, Rasmus Lerdorf wrote:

On 01/29/2013 04:47 PM, Stas Malyshev wrote:

Hi!

which shows the dreaded zend_optimizerplus.inherited_hack which mimics APC's autofilter hack. I'd love to get rid of this particular bit of confusion/code complexity on the integration.

Ohh, this one. IIRC that has to do with conditional definition of classes and the fact that script may be compiled in one environment but loaded in another, which may create difference in class tables, especially combined with early binding for inherited classes. Getting rid of it is not that easy until people stop writing code like: if($foo) return; class Foo extends Bar {} which would work differently depending on if Bar is defined or not.

Yes, I am quite familiar with it since we had to handle this in APC too. But I don't think getting rid of it is that hard. It obviously can't be done in the opcode cache because by the time the compiler hands us the op_array we have already lost the FETCH_CLASS opcode which we may or may not need. We need to look at whether that MAKE_NOP() call in the compiler is actually a worthwhile optimization in a future where most people will be running an opcode cache by default. This is one of the prime examples of making the compiler more opcode cache friendly. Yes, it may be at the slight expense of non-opcode cache performance, but with a bundled opcode cache implementation that should be less of a worry. +1. This one makes no sense to me as it simply hoists the zend_do_inheritance() from runtime binding to compile-time, and this binding has to be backed out by any opcode cache to work properly. It might save a few microseconds per class declaration in non-cached performance, but add factors more to cached performance. Why do this?