Profilers identify bottlenecks in Perl programs
SmallProf Line Profiler
Of course, some modules do not have very sophisticated logging mechanisms. Thankfully, Perl has a number of profilers that measure the amount of time each line of source code uses.
Table 1 shows the major CPAN profilers for various tasks in ascending release order.
The CPAN Devel::SmallProf line profiler autonomously measures run times and formats the data for analysis. If you launch the script you want to test via perl -d:SmallProf ./amzn, the profiler creates a smallprof.out file that lists the time used by each line in each module used.
In the case of a fairly complex action like a web request and ensuing XML analysis of the returned data, the resultant file can be enormous – in this case, it weighed in at no fewer than 25,792 lines.
Discovering the worst time hogs is not an easy task, but the shell command
sort -k 2,2 smallprof.out | less
sorts the file numerically on the second field from the left. This field contains the wall clock time in seconds used by a line of source code, which is the time actually used whether the task gave the CPU something to do or just left it idle, waiting for external events, such as incoming network packages, for example. In addition, the third field contains the CPU seconds, which is the computational time actually used.
If you scroll down to line 17,104 in smallprof.out, as shown in Figure 3, you will see that the line responsible for the wait issues a select command. The can_read function in the LWP::Protocol::http::SocketMethods module is responsible for this.
The CPAN module Devel::NYTProf is a relatively new development . The strange-sounding name came about because the module was developed for the New York Times and based on the Devel::FastProf codebase. Their IT department decided to release the source code.
This excellent profiler is maintained by DBI inventor Tim Bunce  today. Bunce presented his work to the Perl community at OSCON 2008 . Although I was in the audience, I couldn't concentrate on his talk because I was up next with my Log4perl talk.
After the CPAN shell-assisted installation (perl -MCPAN -e'install Devel::NYTProf'), you type perl -d:NYTProf amzn to launch the profiler on the script. To convert its binary logfile nytprof.out to professionally formatted HTML, use the nytprofhtml script included with the package.
Firing up a browser and pointing it to the index.html file in the newly created nytprof directory (URL file:///...nytprof/index.html) reveals what has been going on. The table in Figure 4 lists the hotspots. It shows the number of calls, the number of places (P) they have been issued, the files (F) they are located in, and the time spent executing each function. The tool differentiates between "exclusive time" and "inclusive time," the former referring to the time spent exclusively in the function's code and the latter referring to the total time, including the subfunctions called by the function.
The HTML links the function names with HTML pages providing details on the function code – a very practical idea that lets the user flip back and forth and greatly facilitates the analysis. Figure 5, for example, shows details that were very difficult to obtain with SmallProf; that is, the select() command in the can_read() function in an LWP module is causing the delays. On an open network socket, it waits for the first signs of the response returned by Amazon.
NYTProf supports three different reporting modes for displaying the time spent by the source code: line mode (one time value per line), block mode (one time value per block of Perl), and sub mode (one time value per function). Clicking toggles the performance de-tective through the different display variants.
The module-level view of the profiler in Figure 6 also reveals some interesting facts. The XML analysis of the Amazon web response took 9,963 lines of code and 400 calls to the collapse() function XML::Simple.
Because it ran at full speed, the whole kit and caboodle took just 35msec, but this just goes to show how complex it is to parse XML.
Buy this article as PDF
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.
Four-inch-long computer on a stick lets you boot a full Linux system from any HDMI display device.
New statute would require companies to report break-ins to consumers.
Weird data transfer technique avoids all standard security measures.
FIDO alliance declares the beginning of the end for old-style login authentication.