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" <[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
