Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:41842 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10073 invoked from network); 10 Nov 2008 22:13:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Nov 2008 22:13:20 -0000 Authentication-Results: pb1.pair.com smtp.mail=shire@tekrat.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=shire@tekrat.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain tekrat.com from 69.63.177.213 cause and error) X-PHP-List-Original-Sender: shire@tekrat.com X-Host-Fingerprint: 69.63.177.213 sizzo.org Linux 2.6 Received: from [69.63.177.213] ([69.63.177.213:58704] helo=sizzo.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/F1-34173-FF1B8194 for ; Mon, 10 Nov 2008 17:13:20 -0500 Received: from [172.24.57.110] (outbound500a.pasd.tfbnw.net [204.15.21.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sizzo.org (Postfix) with ESMTPSA id F2EA26D4A22; Mon, 10 Nov 2008 14:13:16 -0800 (PST) Cc: Graham Kelly , "Lukas Kahwe Smith" , "Karoly Negyesi" , internals@lists.php.net Message-ID: <38820B1D-6D5F-4B42-9FEE-0CDF23142A57@tekrat.com> To: shire In-Reply-To: <4022974B-4A13-4AB0-A282-973503200406@tekrat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 14:13:16 -0800 References: <7e270cea0810191211w2cb77075y5e0ad78c2f7306f7@mail.gmail.com> <243C7392-C6A0-4EE8-8AAA-34964E78D453@tekrat.com> <4022974B-4A13-4AB0-A282-973503200406@tekrat.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [PHP-DEV] An optimization idea From: shire@tekrat.com (shire) On Nov 6, 2008, at 10:37 AM, shire wrote: >> >> >> However, while the common compare_function call probably wouldent >> gain anything from this, maybe it could be put in the >> TYPE_PAIR(IS_STRING, IS_STRING) case or put into zendi_smart_strcmp >> (which only seems to ever be called by the TYPE_PAIR(IS_STRING, >> IS_STRING) case of compare_function). >> >> I havent played with the patched version of zend_hash_compare to >> see if it might provide any real world savings. Though it appears >> as if that function might see a significant improvement for these >> cases. > > Arrays and strings do seem to be the only real worth while > comparisons for this type of optimization, but only because the > costs of comparing long strings and large array lists make the > savings more significant. I think it might be hard to see this in a > real world application though, so it would be nice if someone could > justify the change by showing test results. I'll try to bench > Facebook's code base to see what we can get out of it. I just ran a quick benchmark on this and I'm not seeing a significant real world change for Facebook's codebase. (definitely less than 1%) This was a pretty small test, without a lot of code execution, so I could see other applications doing better. I'm pretty neutral on this one, it's not a really big change so might be worth adding if it's going to give a few applications out there a gain, but I couldn't see doing this everywhere of course. -shire