Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65527
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
Message-ID: <510A37E2.6060001@ellisons.org.uk>
Date: Thu, 31 Jan 2013 09:22:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Christopher Jones <christopher.jones@oracle.com>,
 Zeev Suraski <zeev@zend.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <5d21b42656d49b4a71d9f808541bd745@mail.gmail.com> <51078485.30107@rotorised.com> <11e1ccc6eca996d9d94ae9a3bff0bbab@mail.gmail.com> <5108667C.1030901@oracle.com> <510868DE.7010408@lerdorf.com> <51086DB0.8050706@sugarcrm.com> <51086F59.6030007@lerdorf.com>
In-Reply-To: <51086F59.6030007@lerdorf.com>
Content-Type: multipart/alternative;
 boundary="------------060304060608030605080301"
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
From: Terry@ellisons.org.uk (Terry Ellison)

--------------060304060608030605080301
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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?


--------------060304060608030605080301--