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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > >> 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. > >> > >> -Rasmus > > > > > Best regards, > Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
