Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48460 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46918 invoked from network); 25 May 2010 02:37:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 May 2010 02:37:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=spam@geleia.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=spam@geleia.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain geleia.net from 212.113.174.24 cause and error) X-PHP-List-Original-Sender: spam@geleia.net X-Host-Fingerprint: 212.113.174.24 mx.netcabo.pt Received: from [212.113.174.24] ([212.113.174.24:63420] helo=mx.netcabo.pt) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 64/7A-18125-3083BFB4 for ; Mon, 24 May 2010 22:37:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG7U+ktThGjh/2dsb2JhbACdeXKIK7VahRME Received: from a83-132-104-225.cpe.netcabo.pt (HELO geleia.net) ([83.132.104.225]) by neti02smtpa.hdi.tvcabo with ESMTP; 25 May 2010 03:37:52 +0100 Received: from www.geleia.net ([192.168.1.2]) by geleia.net with hMailServer ; Tue, 25 May 2010 03:35:04 +0100 Received: from 93.108.152.52 (SquirrelMail authenticated user spam) by www.geleia.net with HTTP; Tue, 25 May 2010 03:35:04 +0100 (GMT Daylight Time) Message-ID: <65138.93.108.152.52.1274754904.squirrel@www.geleia.net> In-Reply-To: <4BF24049.90408@zend.com> References: <4BF24049.90408@zend.com> Date: Tue, 25 May 2010 03:35:04 +0100 (GMT Daylight Time) To: "Dmitry Stogov" Cc: "PHP Internals" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Run Time Cache RFC From: spam@geleia.net 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