Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:22383 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59279 invoked by uid 1010); 13 Mar 2006 21:22:26 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 59264 invoked from network); 13 Mar 2006 21:22:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Mar 2006 21:22:26 -0000 X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6 Received: from ([81.169.182.136:55142] helo=strato.aixcept.de) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id EA/A8-55982-192E5144 for ; Mon, 13 Mar 2006 16:22:25 -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 1EF9F35C1D2; Mon, 13 Mar 2006 22:22:22 +0100 (CET) Date: Mon, 13 Mar 2006 22:20:29 +0100 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <1914614308.20060313222029@marcus-boerger.de> To: Ron Korving Cc: internals@lists.php.net In-Reply-To: References: <4414F63F.5030406@lerdorf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Calling performance geeks From: helly@php.net (Marcus Boerger) Hello Ron, that stuff is only used in edgcases however it is more of a fix than an optimization. Do you have access and want to do the changes yourself? regards marcus Monday, March 13, 2006, 10:08:30 PM, you wrote: > Hi, > If you're even interested in the tinyest of optimizations, you may wanna > read this. I was just going through the php code. I'm not familiar with it > at all, so I don't know which functions are the bottlenecks, so I can't help > in optimizing the big picture. But I had little else to do right now, so I > figured I'd just browse around through the files to see if I could notice > any local speedups. So really, the things I lay out here are probably > futile, but who knows. > ----- > I found that for example the function php_stream_memory_seek() in > main/streams/memory.c contains a whole bunch of return statements. I found > that it can be (you can benchmark this) slightly faster to do this: > int func(int p) > { > int result = 0; > switch (p) > { > case 0: result = 1; break; > case 1: result = -4; break; > case 2: result = 15; break; > } > return result; > } > instead of this: > int func(int p) > { > switch (p) > { > case 0: return 1; > case 1: return -4; > case 2: return 15; > } > return 0; > } > This is correct with 'gcc foo.c' as well as with 'gcc -O2 foo.c'. The > difference is slight, and if it's too tiny, just ignore it this message. > Perhaps some functions that php relies on heavily may benefit from this > though (but I wouldn't know which ones those would be). > ----- > Also, I noticed that in php_start_ob_buffer() in main/output.c, and probably > in more functions integers are divided by 2 by doing: > result = intvar / 2; > while it is about 20% faster (even with -O2) to do this: > result = intvar >> 1; > ----- > A minor thing I noticed (nothing to speed up here though) is an unused > variable 'i' in insertionsort() in main/mergesort.c (weird that this never > showed up as a compiler warning). Or does the defined TSRMLS_CC depend on > the existance of an integer called 'i'? Pretty unlikely to me. > ----- > Why is CONTEXT_TYPE_IMAGE_GIF in main/logos.h defined as "Content-Type: > image/gif" with 2 spaces between "Content-Type" and "image/gif"? > ----- > In sapi/apache/mod_php5.c in the function php_apache_log_message(), > Why are these 2 calls: > fprintf(stderr, "%s", message); > fprintf(stderr, "\n"); > instead of 1 call: > fprintf(stderr, "%s\n", message); > ----- > In sapi/apache/mod_php5.c in the function php_apache_flag_handler_ex(), > the original: > if (!strcasecmp(arg2, "On") || (arg2[0] == '1' && arg2[1] == '\0')) { > bool_val[0] = '1'; > } else { > bool_val[0] = '0'; > } > is over 5 times slower than: > if (((arg2[0] == 'O' || arg2[0] == 'o') && (arg2[1] == 'n' || arg2[1] == > 'N') && (arg2[2] == '\0')) || (arg2[0] == '1' && arg2[1] == '\0')) { > bool_val[0] = '1'; > } else { > bool_val[0] = '0'; > } > ----- > Like I said, these are extremely tiny things, so please ignore it if it's > too futile :) Nonetheless, if this turns out to be appreciated information, > I'll continue the hunt. > Good luck optimizing, > Ron > "Rasmus Lerdorf" wrote in message > news:4414F63F.5030406@lerdorf.com... >> 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