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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
