44

I need to improve the performance of my Perl application. How can I find the slow spots?


This is a question from the official perlfaq. We're importing the perlfaq to Stack Overflow.

Community
  • 1
  • 1
perlfaq
  • 1,361
  • 4
  • 15
  • 23
  • FWIW, the perlperf manual has a section on profiling tools, though I have no idea how up-to-date it is: https://perldoc.perl.org/perlperf.html#PROFILING-TOOLS – Lekensteyn Sep 22 '18 at 09:48

3 Answers3

53

(This is the official perlfaq answer, minus any subsequent edits)

The Devel namespace has several modules which you can use to profile your Perl programs. The Devel::DProf module comes with Perl and you can invoke it with the -d switch:

$ perl -d:DProf program.pl

After running your program under DProf, you'll get a tmon.out file with the profile data. To look at the data, you can turn it into a human-readable report with the dprofpp program that comes with Devel::DProf:

$ dprofpp

You can also do the profiling and reporting in one step with the -p switch to dprofpp:

$ dprofpp -p program.pl

The Devel::NYTProf (New York Times Profiler) does both statement and subroutine profiling. It's available from CPAN and you also invoke it with the -d switch:

$ perl -d:NYTProf some_perl.pl

Like DProf, it creates a database of the profile information that you can turn into reports. The nytprofhtml command turns the data into an HTML report similar to the Devel::Cover report:

$ nytprofhtml

CPAN has several other profilers that you can invoke in the same fashion. You might also be interested in using the C to measure and compare code snippets.

You can read more about profiling in Programming Perl, chapter 20, or Mastering Perl, chapter 5.

perldebguts documents creating a custom debugger if you need to create a special sort of profiler. brian d foy describes the process in The Perl Journal, "Creating a Perl Debugger", and "Profiling in Perl".

Perl.com has two interesting articles on profiling: "Profiling Perl", by Simon Cozens, and "Debugging and Profiling mod_perl Applications", by Frank Wiles.

Randal L. Schwartz writes about profiling in "Speeding up Your Perl Programs" for Unix Review and "Profiling in Template Toolkit via Overriding" for Linux Magazine.

Nikhil Jain
  • 8,232
  • 2
  • 25
  • 47
brian d foy
  • 129,424
  • 31
  • 207
  • 592
14

I've switched over to using Devel::NYTProf, which is all the best profiling for Perl combined, initially by the folks at the NYTimes.

brian d foy
  • 129,424
  • 31
  • 207
  • 592
Randal Schwartz
  • 39,428
  • 4
  • 43
  • 70
  • 3
    Thanks Randall! (I know this is an old post.. Missed it initially). Tim Bunce has been maintaining it for a while. – Adam Kaplan Nov 24 '11 at 00:19
3

There's a very simple way to find the slow spots so you can improve the performance of your program - random-pausing.

Basically, the idea is, rather than measure to see what part is slow, you let its slowness expose it to you.

Run the program with the debug flag -d, and while it's running, interrupt it manually, and display the call stack (T). Do this a few times, like 5 or 10. Look for any statement that appears on more than one stack and that isn't strictly necessary, because the time it is responsible for is roughly the percent of stacks that show it.

This finds not only hotspots, but lines where functions are being called expensively. It works just as well whether the program is I/O or CPU bound, and it doesn't matter what else is going on in the machine.

You can do it more than once, until you can no longer find anything that can be speeded up.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • 2
    While I acknowledge this technique will work, it is very in efficient, error prone, scales poorly to large code bases, and it won't help you determine if a change really helps your program or just shifts bottlenecks around. For less effort a real profile run will expose much more detail and will likely be more reproducible. – Ven'Tatsu Dec 08 '10 at 18:32
  • 2
    @Ven'Tatsu: Is that what you know, or what you might want to think? In fact it is quite efficient, not error prone, works better with larger code bases, finds real "bottlenecks", gives you just the right detail, and is as reproducible as necessary. [Here's more on the subject.](http://stackoverflow.com/questions/4387895/if-profiler-is-not-the-answer-what-other-choices-do-we-have/4390868#4390868) – Mike Dunlavey Dec 08 '10 at 19:11
  • 1
    I doubt that this will work that well with Perl programs. At least not as well as it would with C for example. Besides running with [Devel::NYTProf](http://search.cpan.org/perldoc/Devel::NYTProf) `perl -d:NYTProf some_perl.pl` generates very nice html pages which are easy to look through. – Brad Gilbert Dec 09 '10 at 18:23
  • 1
    @Brad: Doubt is good, and from what I read of NYTProf I see good things, like reporting by lines of code, and using wall-clock time. I didn't see it showing percent time, but maybe I missed it. Html pages are pretty, I'm sure, but what really matters is what does it tell you. If you can examine a representative call stack in detail, you can see if that piece of time was *not being well spent*, and those are the gold nuggets of tuning. [Measurements are less important.](http://stackoverflow.com/questions/4387895/if-profiler-is-not-the-answer-what-other-choices-do-we-have/4390868#4390868) – Mike Dunlavey Dec 09 '10 at 23:02
  • @Mike Dunlavey: "while it's running, interrupt it manually". How can it be interrupted manually? I tried in Windows CMD.EXE and in Cygwin, with the infinite loop "perl -de "while (1) {}"", followed by "c". In Cygwin Ctrl+Z stopped the infinite loop (or rather, the execution), but that is for the entire perl process, not the debugger. – Peter Mortensen Jan 02 '11 at 12:48
  • @Peter: I'm not a perl expert, but I [just found this](http://use.perl.org/comments.pl?sid=43417) on-line. Also [this](http://use.perl.org/~jjore/journal/39319). – Mike Dunlavey Jan 02 '11 at 16:37
  • @Mike Dunlavey: thanks, I gave the second method a try (in Cygwin), but no useful result (although I got a three-line stack trace - perhaps the code is too trivial). I will also try the first method; if it doesn't work I will open a new Stack Overflow question. – Peter Mortensen Jan 02 '11 at 19:28
  • @Peter: That must be the stack trace of the C interpreter? I would think the more useful stack trace would be the interpreter's stack of perl functions calling each other, because the perl code is the only thing you can edit. I guess I'm confused. (It doesn't matter if you can't restart from where you stopped it. It only matter that you be able to see what it was doing when you stopped it.) – Mike Dunlavey Jan 02 '11 at 20:46