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