Ron Korving wrote:
If this is possible, like Dmitry said, with a macro, that would be
interesting. I'm curious what this macro would look like. Personally, I tend
to go for the less readable solution if the performance advantage is
definately there. A little comment to the code should always be able to
clearify it for any reader. But of course, in this case, it is all entirely
up to you guys.
I would suggest taking a sample script that does some of the stuff you
are interested in speeding up and running Callgrind on it. I find that
I am terrible at guessing where performance bottlenecks are. Actual
profiling wins every time. And it really isn't hard to do. Here is a
little primer geared at profiling an Apache/PHP setup. Doesn't change
much for other environments:
1. If you don't have an x86 Linux box already, get one.
2. Install valgrind, valgrind-callgrind on the Linux machine
3. Install GraphViz and kcachegrind on whatever machine you want to view
the output on. I tend to run kcachegind on my Linux box with the
DISPLAY set to my Powerbook. You can even install it on Windows via
cygwin and I think there is a Wincachegrind thing out there too. For
a really good time, try: fink install kcachegrind on OSX.
4. Install whatever version of PHP you want to test. I tend to have
multiple versions installed at all times and just flip the LoadModule
line around in my httpd.conf file.
5. callgrind --dump-instr=yes --trace-jump=yes -v /usr/sbin/apache -X
6. Hit the server. I tend to hit it about 1000 times to test
per-request stuff. That drowns out any startup stuff. It is
possible to reset the counters after startup using
callgrind-control,
but I tend to not bother.
7. One little quirk is that callgrind creates its output file at
startup, but then Apache switches users and it can't dump its output
at the end. So when you are done hitting the server, do a:
chmod a+rw call*
from another terminal window in the directory you ran callgrind in to
make sure it can write its output.
8. Hit control-C in the callgrind terminal window
9. Congratulations, you now have a callgrind dump. Fire up kcachegrind
in the same directory and you should see all sorts of pretty
pictures.
It might not be a bad idea to create a repository of callgrind dumps.
They are completely portable and can be navigated by any kcachegrind
anywhere. If enough people run these every now and then, we can catch
performance regression quickly.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
