The Perl You Need to Know: Benchmarking Perl Page 6

Due to the scoping of my variables, you can re-use and inside each subroutine without conflict. Remember to modify the label for each benchmark so that you can recognize which subroutine the measurement applies to. When the script runs, for instance in a Web environment, the resulting Web page may then contain a rundown for each subroutine and its execution time. Because this technique does not perform many iterations, you should invoke the script a number of times to get a sense of consistency from the measurements.

Ultimately, the goal of adding stopwatches to your script is to find any abnormally slow subroutines or sections of code. This quick diagnosis can point you to trouble spots quickly. In the long run, focusing on the unusually slow sections of code will yield greater efficiency than attempting to benchmark alternatives for every routine in the script.

Troubleshooting in Context

Finding a slow segment of code is one thing - identifying the hold-up, and a solution, can be quite another. As we saw in earlier examples, there are many times that the Perl language itself can be the source of slow performance. We've seen that there can be a variety of ways to address a problem, using Perl, and some are much faster than others. As a general rule of thumb, Perl will perform faster when you rely on built-in functions; for example, we saw that the map function performed much faster than building a foreach loop of our own. The lesson here is "don't re-invent the wheel" - let Perl do the work, whenever possible.

Equally important to identifying slow Perl syntax, though, are considerations beyond the language itself. For example, if a particular subroutine is accessing data, consider where the data is stored. Data retrieved from disk will likely be slower than data retrieved from memory. Beyond that, the retrieval time of data on disk can vary considerably, depending on whether the data is stored in a simple, slow database or a fast, indexed database. In any case, the delay in retrieving data will inflate the execution time of such a subroutine, without being the fault of the Perl code itself, but of the larger architecture.

Similarly, when a Perl subroutine retrieves data from a database, does it establish a connection to the database on each invocation, or can it rely on an existing connection already established (known as "persistent connections")? Again, this bottleneck can inflate the execution time of such a segment of code.

Portions of code that make network requests are going to be subject to all of the delays inherent in networks. Once again, reducing these bottlenecks may not involve changing the Perl code at all, but changing the architecture of the system, whether that includes other pieces of software or the hardware itself. Ultimately, the point is that measuring execution time of code is important, but intepreting it in context is even more important: the code itself may, or may not be, to blame for a bottleneck.

This article was originally published on Jan 23, 2001
Page 6 of 6

Thanks for your registration, follow us on our social networks to keep up-to-date