Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Profiling a large program

by keymon (Beadle)
on Oct 27, 2006 at 11:01 UTC ( #580931=perlquestion: print w/replies, xml ) Need Help??

keymon has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

I come here seeking some tips on how to profile a rather large piece of Perl code, with 100s of classes, etc. which runs under Apache using modperl. This is an internal application that has grown over the years, and now threatens to eat everyone alive (ok, not really :) ). It is slow, and there are severe memory leaks. I would like to figure out what are the most time-consuming methods, and where's the memory being leaked.

If it were standalone, I could use DProf and slog my way through that. But are there any better ways?

Consider for example the memory leaks. Is there a way to dump out the allocated objects periodically, and see which ones are not being freed?

As for runtime: is there a way to add instrumentation at the very low level (instead of modifying each method in each class, one by one) to get a list of the top resource hogs?

Your help, advice and perls(!) of wisdom would be greatly appreciated.

Replies are listed 'Best First'.
Re: Profiling a large program
by philcrow (Priest) on Oct 27, 2006 at 11:14 UTC
Re: Profiling a large program
by wazzuteke (Hermit) on Oct 27, 2006 at 11:24 UTC
    Although you mention DProf as your profiler of choice, I've also liked running Apache::SmallProf which allows the hooks from Devel::SmallProf into mod_perl. In any event, both SmallProf and DProf are really handy tools for mod_perl based applications.

    Good luck!

    perl -le '$.=[qw(104 97 124 124 116 97)];*p=sub{[@{$_[0]},(45)x 2]};*d=sub{[(45)x 2,@{$_[0]}]};print map{chr}@{p(d($.))}'
Re: Profiling a large program
by perrin (Chancellor) on Oct 27, 2006 at 15:36 UTC
    You can try PadWalker and Devel::Cycle for finding variables that are not getting freed. However, growth in memory doesn't always mean that you have memory leaks. It may just mean that you are loading something large into some of your variables at some point. The memory will stay allocated there one it has been used, even if the variable is garbage collected.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://580931]
Approved by ww
Front-paged by andyford
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (7)
As of 2023-11-30 16:47 GMT
Find Nodes?
    Voting Booth?

    No recent polls found