Thanks for the info. I do have a Linux box, but that one needs uptime. I'll need a new one I can screw up while developing on it. I think I'll buy me one soon, so I can do these kind of things in the future.
Thanks again, Ron "Rasmus Lerdorf" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > 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
