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?
