Re: Run Time Cache RFC

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.