Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:22377 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93502 invoked by uid 1010); 13 Mar 2006 18:20:30 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 93487 invoked from network); 13 Mar 2006 18:20:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Mar 2006 18:20:30 -0000 X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:18412] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 4D/11-55982-DE7B5144 for ; Mon, 13 Mar 2006 13:20:30 -0500 Received: (qmail 26025 invoked from network); 13 Mar 2006 18:20:24 -0000 Received: from localhost (HELO ANDI-NOTEBOOK.zend.com) (127.0.0.1) by localhost with SMTP; 13 Mar 2006 18:20:24 -0000 Message-ID: <7.0.1.0.2.20060313101833.0453f4a0@zend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 13 Mar 2006 10:20:19 -0800 To: Rasmus Lerdorf Cc: internals In-Reply-To: <44150E03.70500@lerdorf.com> References: <4414F63F.5030406@lerdorf.com> <7.0.1.0.2.20060312211612.04c96438@zend.com> <44150E03.70500@lerdorf.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] Calling performance geeks From: andi@zend.com (Andi Gutmans) Hey, 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. It'd be helpful if others also run such an empty benchmark because it seems like the two trees are on par now and that it depends more on your hardware architecture than the PHP versions.... But if we can get some more results that would give us a clue. In any case, we can try and optimize further especially the startup/shutdown routines... Andi At 10:15 PM 3/12/2006, Rasmus Lerdorf wrote: >With an empty.php file 0 bytes long I get: > >PHP 5.1.3-dev (no opcode cache, variables_order=GP) 1168-1225 >req/sec over 5 runs of 10000 requests each. > >PHP 4.4 same config 1897-1951 req/sec > >Just to make sure, since in this case an extra header would make a >big difference, the raw headers that came back on both: > >HTTP/1.1 200 OK >Date: Mon, 13 Mar 2006 05:31:51 GMT >Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.4.3-dev >X-Powered-By: PHP/4.4.3-dev >Connection: close >Content-Type: text/html; charset=iso-8859-1 > >HTTP/1.1 200 OK >Date: Mon, 13 Mar 2006 05:35:49 GMT >Server: Apache/1.3.33 (Debian GNU/Linux) PHP/5.1.3RC2-dev >X-Powered-By: PHP/5.1.3RC2-dev >Connection: close >Content-Type: text/html; charset=iso-8859-1 > >So yes, there are a few characters more, but I checked 5.1.2 as well >which actually has less, and it is about the same speed. > >And here are some pretty pictures from kcachegrind since I realize >many don't have the ability to run it. These show an overview of >1000 requests for a 0 byte php file. I start at the whole request >and zoom in on request_startup and then hash_environment on each: > >http://www.php.net/~rasmus/bm/php51_empty.png >http://www.php.net/~rasmus/bm/php51_empty_startup.png >http://www.php.net/~rasmus/bm/php51_empty_hash_env.png >http://www.php.net/~rasmus/bm/php44_empty.png >http://www.php.net/~rasmus/bm/php44_empty_startup.png >http://www.php.net/~rasmus/bm/php44_empty_hash_env.png > >You will notice things missing from each. Basically kcachegrind is >only showing things that took a significant portion of the execution >time, so for PHP44 you will see much more of the Apache stuff >showing up since the PHP parts were so fast. Here you can see the >crazy qsort called from ap_add_common_vars() if you look at the >right side of the php44_empty.png picture. > >The corresponding callgrind raw files are: > >http://www.php.net/~rasmus/bm/callgrind.out.2464 PHP 5.1 >http://www.php.net/~rasmus/bm/callgrind.out.2548 PHP 4.4 > >You can load these up in kcachegrind and zoom in on other stuff. > >-Rasmus > >Andi Gutmans wrote: >>What are the results you're getting on an empty script? I'm just >>curious whether it's execution speed or startup speed where you are >>seeing the big hit. There were changes in both which might have >>slowed things down. Another reason to be more careful re: bloat :) >>Anid >>At 08:34 PM 3/12/2006, Rasmus Lerdorf 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: >>> >>>>>'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 << >>>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 >>> >>>-- >>>PHP Internals - PHP Runtime Development Mailing List >>>To unsubscribe, visit: http://www.php.net/unsub.php