Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36146
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <47DABFB3.8040705@lerdorf.com>
Date: Fri, 14 Mar 2008 11:10:59 -0700
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
CC: Stanislav Malyshev <stas@zend.com>, Dmitry Stogov <dmitry@zend.com>,
        Andi Gutmans <andi@zend.com>, internals@lists.php.net
References: <06B0D32C7A96544490D18AF653D6BDE5026BA3C7@il-ex1.zend.net> <3210620415.20080314173251@marcus-boerger.de> <47DAAD25.4000507@zend.com> <1539788104.20080314182355@marcus-boerger.de>
In-Reply-To: <1539788104.20080314182355@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Patch for opcode caches
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Marcus Boerger wrote:
> Hello Stanislav,
> 
> Friday, March 14, 2008, 5:51:49 PM, you wrote:
> 
>>> But that means we are compiling inheritance when a file is loaded form
>>> the cache. The goal should be to compiling inheritance when writing to
>>> the opcode cache file. All we achieve here is a slow down. If there is
> 
>> You can not do that. You do not know that until runtime.
> 
>>> something that makes this required than at least we need to warn the user
>>> about the slow code. I Think what we need to do is deprecating class and
> 
>> It won't be slow. It would be much faster (in some cases 10x faster). 
>> This specific assembly of instructions might be slower in some cases, 
>> but the code altogether will be faster. That's the idea of the opcode 
>> caches.
> 
>>> namespace use in non main blocks as well as include and require in non
>>> main blocks. And if there is no such case than everything can be bound
>>> early which is the fast state we should aim for.
> 
> Lemme just think, doing inheritance at compile time before we send the stuff
> to an opcode cache can be slower then? How is that possible? After all late
> binding means we do it at run time. And no matter how much faster we can do
> it. It will always be slower than doing the same thing only once.
> 
>> We do not need to deprecate anything, and inheritance can not be bound 
>> before parent class is known, which in the case of bytecode cache means 
>> - not before the file is loaded from the cache. That's exactly what this 
>> patch enables. It does not change performance characteristics of neither 
>> cached not non-cached code, it just makes it much simpler and working in 
>> all cases.
> 
> Inheritance cannot be done before the parent class is known. We still need
> to do the prototype checks even if we assume the class is there and insert
> a virtual class as parent somehow.

I don't actually see early binding as being much of a problem, the real 
problem is when the same class is both early and late bound.  If you 
consistently always bind early or always bind late, opcode caches should 
be quite happy to let you do that.  But if you mix the two, things get 
chaotic and the problem becomes intractable.  We went through all this 
in APC a couple of years ago.  My initial, somewhat naiive attempt at 
fixing it:

   http://news.php.net/php.pecl.cvs/4288

That obviously wasn't enough to fix it, so essentially we end up simply 
detecting the scenario and not doing early binding for classes that are 
detected to also be bound late:

   http://pecl.php.net/bugs/bug.php?id=5314

-Rasmus