Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48461
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <4BFB6C00.7070404@zend.com>
Date: Tue, 25 May 2010 10:19:44 +0400
User-Agent: Thunderbird 2.0.0.23 (X11/20090825)
MIME-Version: 1.0
To: spam@geleia.net
CC: PHP Internals <internals@lists.php.net>
References: <4BF24049.90408@zend.com> <65138.93.108.152.52.1274754904.squirrel@www.geleia.net>
In-Reply-To: <65138.93.108.152.52.1274754904.squirrel@www.geleia.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Run Time Cache RFC
From: dmitry@zend.com (Dmitry Stogov)

Hi,

spam@geleia.net wrote:
> On Tue, May 18, 2010 8:22 am, Dmitry Stogov wrote:
>> I'm proposing another optimisation technique implementation for PHP
>> which makes up to 20% speed up on synthetic tests and up to 8% speed up on
>> real-life applications.
>>
>> The technique is similar to "inline caches" which is very popular in JIT
>> compilers for object oriented languages.
>>
>> http://wiki.php.net/rfc/runtimecache
>>
>>
>> The patch breaks binary and source compatibility but it's not hard to
>> adopt extensions to use it.
>>
>> I'm going to commit the patch on next week in case of no objections.
> 
> First, I'm sorry I didn't bring this before (as in "before the commit"),
> but I missed this thread.
> 
> As I understand, this patch adds a new place (a regular array) wherein the
> properties are stored. They can now be in the properties hashtable, in the
> properties_table array, or in both (but for refcount purposes they're only
> stored in one place). Dynamic properties require the hash table.

Exactly.

> This feels very hackish. I'm probably missing a crucial point, but why not
> store everything in properties hash table and then store the zval**'s also
> in the properties_table if needed.

The HashTable construction/destruction takes significant time and more 
memory, however most operations with declared properties don't require 
HashTable at all. In case you compare the Zend/micro_bench.php output 
before and after the patch you'll see a big speedup on ZEND_NEW opcode 
which is cause by new object structure.

The very similar technique is already used in PHP for lazy symbol table 
initialization.

> This would avoid having to check
> whether the hashtable is built and build it if not -- Is there such a
> significant performance penalty? The API is already clumsy enough and this
> is bi-storage of properties is something a beginner would find hard to
> understand (though I understand this will probably not impact the
> extensions that just use the handlers to access the properties).

Of course. The patch only optimizes low-level operations but the API is 
still the same.

> Finally, how does this impact debugging? Shouldn't there be a way to
> disable caching for debugging purposes?
> 

Debugger may just check and rebuild properties HashTable if it needs it.

Thanks. Dmitry.