views:

677

answers:

4

I am working on a web app that uses Perl and I need to look into speeding up portions of the app.

I thought I'd start profiling the particular calls for the portion I wish to investigate. I've done some searching on profiling Perl code, but unfortunately most of what I find says that I should run my perl code with -d:DProf myapp from the command line. That doesn't quite work for me since my code is within a web app. I did find a way to get the profiling to work with apache, but unfortunately, the "most used" modules that came back from the profiler were all CPAN modules -- Class::xyz, etc etc etc. Not terribly helpful.

Does anyone know of a good way besides me injecting "timer" code into the methods I wish to profile to target just these methods? I've thought of writing a test script and profiling that but due to the nature of the code I'm working on that would require a bit more work than I'm hoping to have to do.

+1  A: 

You can use the Benchmark core module with the :hireswallclock option if you really want to time things internally. But really, you should be able to profile from the command line. You might have to write test scripts to emulate certain portions of a CGI request, but DProf can be extremely useful when looking for performance bottlenecks.

In particular, look for where your code is calling the CPAN module code. You may be doing this in loops far more than necessary, so while the time is spent in the CPAN module, refactoring your code can fix the problem.

Adam Bellaire
+12  A: 
brian d foy
Yeah, that's the one I tried, and all it turned up was all the cpan modules. I want to actually target these specific methods and see where they themselves are spending most of the time.
Leanan
Which CPAN modules did it list? If you're doing a lot of database calls then it's quite possible that DBI and DBD modules will be at the top of your list. This isn't because Perl is doing too much work, but because your DB queries are slow. Start profiling them instead.
mpeters
+6  A: 

If you're using CGI.pm, you can pass arguments to your perl script on the command line and CGI.pm will interpret them as if they were passed as parameters over HTTP. So if you're debugging, e.g.

http://example.com/scripts/example.pl?action=browse&search=grommet&restrict=blah

then you could just call from the command line, e.g.

perl -d:NYTProf documentroot/scripts/example.pl 'action=browse&search=grommet&restrict=blah'

Sam Kington
+1  A: 
Dave Sherohman