Devel::DProf

Matts on 2002-05-01T20:12:10

Devel::DProf and dprofpp are perhaps one of the nicer things about developing performance critical applications in Perl. Other languages really don't seem to come close to the ease with which I can use this tool to locate performance bottlenecks and kill them. I often find myself seeing a particular test that runs slowly, but I know I can just type:

$ perl -Mblib -d:DProf t/slowtest.t $ dprofpp -O 50

and soon all will be revealed. Kudos to the author (I believe it was Ilya, but it's not in the man pages).


And Apache::DProf

rafael on 2002-05-02T07:48:50

I think it was Ilya; but the format of tmon.out is unfortunately not documented. May I point you at my journal entry on Apache::DProf?

Re:And Apache::DProf

Dom2 on 2002-05-02T09:15:02

Apache::DProf is ok, but it's not really a very good tool for the simple reason that you can't pin down individual handlers. Everything gets lumped into one big tmon.out per child.

This means that you have to conduct large scale tests to get an average out of it instead, which is annoying when all you want to do is profile one run.

The other problem (for me) is that Apache::DProf made my apache dump core on the page I was really interested in. Lacking the debugging skills needed, I left it at that. :-(

Overall, I found that the simplest solution was to write my code so that it didn't depend upon apache at all. And the bonus is that I now have a script to access the web based functionality from the command line. And because it's using the same modules I know its doing the same thing.

BTW, after writing the script, I immediately profiled it and spotted my performance problem straight away: 4100 RPC calls per request to the back end! Needless to say, that got optimized out sharpish!

-Dom

Re:And Apache::DProf

Matts on 2002-05-02T09:57:09

Devel::DProf is a bit core dump happy anyway, so I'm not surprised it did that within Apache. It got a lot better in 5.6.1, and I think it'll get better still for 5.8. Lets hope so anyway.