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.
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 give the required or
suggested best-practice changes for extensions?
Thanks,
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Free PHP Book: http://tinyurl.com/ugpomhome
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
Dmitry Stogov wrote:
http://wiki.php.net/rfc/runtimecache
The patch breaks binary and source compatibility but it's not hard to
adopt extensions to use it.
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 :)
The RFC should give enough explanation so (i) extension maintainers
can immediately identify if their extension is going to be affected
(ii) readers know where to look in the patch to get more details.
If I understand what you implied later in your email, calls to
zend_hash_copy should be replaced with calls to
object_properties_init. Is this always true? Is this the only
extension requirement? What happens if extensions don't do this -
will it break or be a performance loss?
I must be looking at a different RFC because there's nothing I can see
that mentions any of these things.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Free PHP Book: http://tinyurl.com/ugpomhome
Hi!
If I understand what you implied later in your email, calls to
zend_hash_copy should be replaced with calls to
object_properties_init. Is this always true? Is this the only
That's probably not so. As I understand, the patch changes the way the
object properties are accessed. So if your extension manipulates
properties of some objects directly, it needs to be changed. This
includes initializing properties (object_properties_init) and accessing
them as hash (which would probably require zend_std_get_properties or
zend_std_get_properties.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Chris,
I've added notes for extension maintainers.
I hope they will answer all your questions.
Thanks. Dmitry.
Christopher Jones wrote:
Dmitry Stogov wrote:
http://wiki.php.net/rfc/runtimecache
The patch breaks binary and source compatibility but it's not
hard to
adopt extensions to use it.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 :)The RFC should give enough explanation so (i) extension maintainers
can immediately identify if their extension is going to be affected
(ii) readers know where to look in the patch to get more details.If I understand what you implied later in your email, calls to
zend_hash_copy should be replaced with calls to
object_properties_init. Is this always true? Is this the only
extension requirement? What happens if extensions don't do this -
will it break or be a performance loss?I must be looking at a different RFC because there's nothing I can see
that mentions any of these things.Chris
Thanks Dmitry - that's great.
Also thanks to Stas for his reply.
Chris
Dmitry Stogov wrote:
Hi Chris,
I've added notes for extension maintainers.
I hope they will answer all your questions.Thanks. Dmitry.
Christopher Jones wrote:
Dmitry Stogov wrote:
http://wiki.php.net/rfc/runtimecache
The patch breaks binary and source compatibility but it's not
hard to
adopt extensions to use it.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 :)The RFC should give enough explanation so (i) extension maintainers
can immediately identify if their extension is going to be affected
(ii) readers know where to look in the patch to get more details.If I understand what you implied later in your email, calls to
zend_hash_copy should be replaced with calls to
object_properties_init. Is this always true? Is this the only
extension requirement? What happens if extensions don't do this -
will it break or be a performance loss?I must be looking at a different RFC because there's nothing I can see
that mentions any of these things.Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Free PHP Book: http://tinyurl.com/ugpomhome
On Mon, May 24, 2010 at 10:46 PM, Christopher Jones
christopher.jones@oracle.com wrote:
Thanks Dmitry - that's great.
I second that, useful info for people with time issues like us :)
Also thanks to Stas for his reply.
Chris
Dmitry Stogov wrote:
Hi Chris,
I've added notes for extension maintainers.
I hope they will answer all your questions.Thanks. Dmitry.
Christopher Jones wrote:
Dmitry Stogov wrote:
>> > http://wiki.php.net/rfc/runtimecache
>> >
>> > The patch breaks binary and source compatibility but it's not hard
to
>> > adopt extensions to use it.>>
>> 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 :)The RFC should give enough explanation so (i) extension maintainers
can immediately identify if their extension is going to be affected
(ii) readers know where to look in the patch to get more details.If I understand what you implied later in your email, calls to
zend_hash_copy should be replaced with calls to
object_properties_init. Is this always true? Is this the only
extension requirement? What happens if extensions don't do this -
will it break or be a performance loss?I must be looking at a different RFC because there's nothing I can see
that mentions any of these things.Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Free PHP Book: http://tinyurl.com/ugpomhome--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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.
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. 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).
Finally, how does this impact debugging? Shouldn't there be a way to
disable caching for debugging purposes?
--
Gustavo Lopes
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.