On 01/31/2013 01:22 AM, Terry Ellison wrote:
> 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?
I agree. And the code doesn't have to be as silly as the example Stas
gave. Something as simple as this will hit it:
indexA includes child1 and child2 which both extend parent1
indexB includes only child2
Assuming these are all in different files, if you hit indexA first, by
the time the compiler gets to child2 parent1 already exists because
child1 inheriting from it brought it in so it will be compiled without
the FETCH_CLASS opcode.
But then you hit the indexB entry point and now the compiled child2 is
used in a context that doesn't already provide parent1 so the cached
opcodes can't be used here.
Of course, if on an empty cache the indexB entry point is hit before the
indexA entry point, then everything is fine. child2 will be compiled
with the "FETCH_CLASS parent1" intact and this version can be used in
both contexts.
This is the kind of thing I really don't want to have to explain to
people with an integrated cache solution. It is a level of detail the
user should never hit.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
