Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36215
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Thu, 20 Mar 2008 11:18:05 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <529079171.20080320111805@marcus-boerger.de>
To: "Dmitry Stogov" <dmitry@zend.com>
CC: internals@lists.php.net
In-Reply-To: <06B0D32C7A96544490D18AF653D6BDE502759909@il-ex1.zend.net>
References: <06B0D32C7A96544490D18AF653D6BDE502759909@il-ex1.zend.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Patch for opcode caches
From: helly@php.net (Marcus Boerger)

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