Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:22365 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40940 invoked by uid 1010); 13 Mar 2006 09:24:25 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 40925 invoked from network); 13 Mar 2006 09:24:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Mar 2006 09:24:25 -0000 X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6 Received: from ([81.169.182.136:53306] helo=strato.aixcept.de) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 89/00-55982-84A35144 for ; Mon, 13 Mar 2006 04:24:24 -0500 Received: from baumbart.mbo (dslb-084-063-002-060.pools.arcor-ip.net [84.63.2.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by strato.aixcept.de (Postfix) with ESMTP id B713F35C1D2; Mon, 13 Mar 2006 10:24:21 +0100 (CET) Date: Mon, 13 Mar 2006 10:22:28 +0100 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <1845610431.20060313102228@marcus-boerger.de> To: Rasmus Lerdorf Cc: internals In-Reply-To: <4414F63F.5030406@lerdorf.com> References: <4414F63F.5030406@lerdorf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Calling performance geeks From: helly@php.net (Marcus Boerger) Hello Rasmus, not a thing for 5.1 or 4.4 but in 5.2 we could change to a case insensitive comparison function. That would allow us to change nearly all of strcasecmp to memcmp. And in may cases it means one less allocation. And it also means a lot of less code. The casinsensitive comparision is pretty easy because we can use a 256 byte translation table that can be provided as a static const table. On a X86 systems we could also provide that in assembler. That would give us the possibility to use the XLAT instruction that would otherwise not be used (maybe newer optimizing compiler know about it though). Maybe it is worse trying to bring it in and checking how much slower we are getting with it. If the numbers look promising we could go for the change then. A word on HEAD/Unicode. If we use a case insensitivity semantics where only the normal ascii characters are lowercased we can use the same table based approach. Anyway from looking at the output the best optimization was brought up by you already. Using jit for the ap_* stuff. best regards marcus Monday, March 13, 2006, 5:34:07 AM, you wrote: > We have a bit of a performance disconnect between 4.4 and 5.1 still. I > was doing some benchmarking today just as a sanity check on some APC > work I have been doing lately and came up with this: > http://lerdorf.com/php/bm.html > You can ignore the apc/eaccelerator stuff. Those numbers are not > surprising. The surprising number to me is how much faster 4.4 still is. > The graph labels are slightly off. The 0, 5 and 10 includes should > really be 1, 6 and 11. The actual benchmark code is here: > http://www.php.net/~rasmus/bm.tar.gz > Tested on a Linux 2.6 Ubuntu box on an AMD chip (syscalls are cheap > there) with current PHP_4_4 and PHP_5_1 checkouts. Was also testing > 5.1.2 to see the effect of getting rid of that uncached realpath call. > As far as I can tell auto_globals_jit isn't working at all, but I > eliminated that by doing variables_order = GP for these benchmarks. > Even so, the request_startup is significantly more expensive in 5.1. > Here are callgrind dumps for each. Load them up with kcachegrind and > browse around: > PHP 4.4 http://www.php.net/~rasmus/callgrind.out.1528.gz > PHP 5.1 http://www.php.net/~rasmus/callgrind.out.1488.gz > Each of these is 1000 requests against the top.php and 4top.php scripts. > from bm.tar.gz. If you start at the > The script is trivial and looks like this: > > $base_dir = '/var/www/bm/'; > include $base_dir . 'config.inc'; > function top_func($arg) { > $b = $arg.$arg; > echo $b; > } > class top_class { > private $prop; > function __construct($arg) { > $this->prop = $arg; > } > function getProp() { > return $this->prop; > } > function setProp($arg) { > $this->prop = strtolower($arg); > } > } > top_func('foo'); > $a = new top_class('bar'); > echo $a->getProp(); > $a->setProp("AbCdEfG"); > echo $a->getProp(); > echo << The database is {$config['db']} > and the user is {$config['db_user']} > EOB; ?>> > > and config.inc is: > $config = array( > 'db' => 'mysql', > 'db_user' => 'www', > 'db_pwd' => 'foobar', > 'config1' => 123, > 'config2' => 456, > 'config3' => 789, > 'sub1' => array(1,2,3,4,5,6,7,8,9,10), > 'sub2' => array("abc","def","ghi","jkl","mno","pqr","stu","vwx","yz") > ); ?>> > 4top.php is identical except for the class definition being PHP 4-style > instead. As in no private and a PHP 4 constructor. Otherwise it is > identical. > I have some ideas for things we can speed up in 5.1. Like, for example, > we should add the ap_add_common_vars() and ap_add_cgi_vars() to the jit > mechanism. There isn't much point filling these in unless the script > tries to get them. the ap_add_common_vars() call is extremely expensive > since it does a qsort with a comparison function that uses strcasecmp. > Of course, this same optimization can be done in 4.4. > If you know your way around kcachegrind, load up the two callgrind files > and see what stands out for you. As far as I can tell, while we can do > some tricks to speed up various helper bits, the slowdown is coming from > the executor trashing its cache lines. > -Rasmus Best regards, Marcus