Pontificating on Perl Profiling

Whenever a Perl program or script is not working as quickly as we think it should, we're all tempted to start pointing at the obvious issue. It's because you're using a four line block to get that hash, you should use ?map?. *That's* your problem. The database is slow, it takes forever to run the query. You're not caching that response, you need to optimize! Ok, so that last one might actually be right. But how do we know? Even if we should optimize, what should we optimize? Where are the real slow downs, and where can we get the biggest wins? The answer to these questions comes from Profiling. At Dyn Inc. we've been writing enterprise grade web applications and software in Perl for over a decade. We think we?re pretty good at. And yet, when we started to experience slow downs on a new system as the user-base grew we spent a lot of time trying to make the code faster.? It wasn't until we took the time to run some of the suspected problematic libs through a profiler that we finally were able to gain some significant speed ups. An 85% speed up in one call alone. We became profiling fools. Maybe more illuminating than where we needed to optimize was where we did not have to. Many assumptions were dashed in the face of data. This talk will guide the beginner Perl user through they whys and hows of code profiling. Attendees will be introduced to the profiling tool Devel::NYTProf, in the context of how Dyn Inc. engineers found a significant speed up based on an inefficient sub routine in a popular CPAN module. Attendees will be shown the tool, and associated output, along with a walk-through of how to interpret the data for best optimization candidates. They will be shown simple techniques for benchmarking and profiling scripts and sub-routines.