Calling performance geeks

> Thanks for posting this info. It definitely sounds like we should > concentrate on the 0 length script at this point. I saw Dmitry already > made some good improvements.

> Hi Marcus,

> Actually, I was looking at the 5.1.2, not 4.4. And 5.1.2 can't differ that > much from 5.1/HEAD, right? I'm not sure if I'm ready for CVS access, since I > don't know enough of the architecture of the system as a whole. I wouldn't > wanna break anything while trying to make things better. If I wanna > collaborate, what's the protocol of applying for a CVS account and is there > info on quality assurance? Are all CVS changes reviewed? I'd like to know > how this works, but don't quite know where to begin. Can you provide me some > basic info to get me informed and possibly get me started?

> Thanks,

> Ron

> "Marcus Boerger" <helly@php.net> wrote in message > news:1531526751.20060313233621@marcus-boerger.de... >> Hello Ron, >> >> just as a clarification, you looked at unchanged 4.4 code that is fixed >> since long in 5.1/HEAD. Please always first look into 5.1/HEAD since 4.4 >> will only get real fixes but no code beautifying. Also we always start to >> modify HEAD first and MFH from there. Doing it the otherway round just >> costs unneccessary development time. >> >> 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" <rasmus@lerdorf.com> 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: >> >> >> >> <html> >> >> <?php >> >> $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 <<<EOB >> >> The database is {$config['db']} >> >> and the user is {$config['db_user']} >> >> >> >> EOB; >> >> ?> >> >> </html> >> >> >> >> and config.inc is: >> >> >> >> <?php >> >> $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.