Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65459
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.128.176 cause and error)
Message-ID: <51086F59.6030007@lerdorf.com>
Date: Tue, 29 Jan 2013 16:54:49 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: 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>
In-Reply-To: <51086DB0.8050706@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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.

-Rasmus