Hi,

I don't have access and I don't need to do the changes myself, but if you
prefer it, I will (provided I get access of course).

Ron


"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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

Reply via email to