Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36219
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <47E25591.2090901@zend.com>
Date: Thu, 20 Mar 2008 15:16:17 +0300
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
CC: internals@lists.php.net
References: <06B0D32C7A96544490D18AF653D6BDE502759909@il-ex1.zend.net> <529079171.20080320111805@marcus-boerger.de>
In-Reply-To: <529079171.20080320111805@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: dmitry@zend.com (Dmitry Stogov)

I hope it must be fixed now.

Dmitry.

Marcus Boerger wrote:
> Hello Dmitry,
> 
>   can you please fix your mail client? You are breaking every single thread
>   you reply to. Thx!
> 
> marcus
> 
> Monday, March 17, 2008, 9:07:41 AM, you wrote:
> 
> 
> 
>>> -----Original Message-----
>>> From: Marcus Boerger [mailto:helly@php.net] 
>>> Sent: Friday, March 14, 2008 8:24 PM
>>> To: Stas Malyshev
>>> Cc: Dmitry Stogov; Andi Gutmans; phpxcache; internals@lists.php.net
>>> Subject: Re: [PHP-DEV] Patch for opcode caches
>>>
>>>
>>> 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?
> 
>> It's always faster, but with opcode caches we cannot always do it in
>> compile-time, because the parent (in another file) might be changed on
>> next load of children class.
> 
>>> 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.
> 
>> Right. This is the reason why we need to delay early binding. But we
>> don't like to delay it to run-time, because it will breake the class
>> creaton order and as result may breake some scripts.
> 
>> Thanks. Dmitry.
> 
> 
> 
> Best regards,
>  Marcus
>