Hi Jones,

Christopher Jones wrote:

Dmitry Stogov wrote:

Hi,

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.

Thanks. Dmitry.

Hi Dmitry,

Can update the RFC to explain the breakage and

It's clear from the patch. The same is explained in RFC in human
language, but it's not so exact :)

Index: Zend/zend.h

--- Zend/zend.h (revision 299422)
+++ Zend/zend.h (working copy)
@@ -298,6 +298,7 @@
typedef struct _zend_object {
zend_class_entry *ce;
HashTable *properties;

• zval **properties_table;
  HashTable guards; / protects from __get/__set ... recursion */
  } zend_object;

@@ -468,11 +469,13 @@
zend_uint ce_flags;

HashTable function_table;

• HashTable default_properties;
  HashTable properties_info;
• HashTable default_static_members;
• HashTable *static_members;

• zval **default_properties_table;

• zval **default_static_members_table;

• zval **static_members_table;
  HashTable constants_table;

• int default_properties_count;

• int default_static_members_count;
  const struct _zend_function_entry *builtin_functions;

  union _zend_function *constructor;

give the required or
suggested best-practice changes for extensions?

Most affected php extensions already fixed with the same patch.
It usually requires just one line change.

Index: ext/dom/php_dom.c

--- ext/dom/php_dom.c (revision 299422)
+++ ext/dom/php_dom.c (working copy)
@@ -1053,7 +1053,6 @@
static dom_object* dom_objects_set_class(zend_class_entry class_type,
zend_bool hash_copy TSRMLS_DC) / {{{ */
{
zend_class_entry *base_class;

• zval *tmp;
  dom_object *intern;

  if (instanceof_function(class_type, dom_xpath_class_entry TSRMLS_CC)) {
  @@ -1075,7 +1074,7 @@

  zend_object_std_init(&intern->std, class_type TSRMLS_CC);
  if (hash_copy) {

•   zend_hash_copy(intern->std.properties, 
  

&class_type->default_properties, (copy_ctor_func_t) zval_add_ref, (void
*) &tmp, sizeof(zval *));

•   object_properties_init(&intern->std, class_type);
  

  }

  return intern;

The complete patch is attached to RFC, and in case anyone likes to
understand it, they have to look into the patch itself.

Thanks. Dmitry.

Thanks,

Chris

Hi,

spam@geleia.net 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.