3 perlperf - Perl Performance and Optimization Techniques
7 This is an introduction to the use of performance and optimization techniques
8 which can be used with particular reference to perl programs. While many perl
9 developers have come from other languages, and can use their prior knowledge
10 where appropriate, there are many other people who might benefit from a few
11 perl specific pointers. If you want the condensed version, perhaps the best
12 advice comes from the renowned Japanese Samurai, Miyamoto Musashi, who said:
14 "Do Not Engage in Useless Activity"
20 Perhaps the most common mistake programmers make is to attempt to optimize
21 their code before a program actually does anything useful - this is a bad idea.
22 There's no point in having an extremely fast program that doesn't work. The
23 first job is to get a program to I<correctly> do something B<useful>, (not to
24 mention ensuring the test suite is fully functional), and only then to consider
25 optimizing it. Having decided to optimize existing working code, there are
26 several simple but essential steps to consider which are intrinsic to any
29 =head2 ONE STEP SIDEWAYS
31 Firstly, you need to establish a baseline time for the existing code, which
32 timing needs to be reliable and repeatable. You'll probably want to use the
33 C<Benchmark> or C<Devel::NYTProf> modules, or something similar, for this step,
34 or perhaps the Unix system C<time> utility, whichever is appropriate. See the
35 base of this document for a longer list of benchmarking and profiling modules,
36 and recommended further reading.
38 =head2 ONE STEP FORWARD
40 Next, having examined the program for I<hot spots>, (places where the code
41 seems to run slowly), change the code with the intention of making it run
42 faster. Using version control software, like C<subversion>, will ensure no
43 changes are irreversible. It's too easy to fiddle here and fiddle there -
44 don't change too much at any one time or you might not discover which piece of
45 code B<really> was the slow bit.
47 =head2 ANOTHER STEP SIDEWAYS
49 It's not enough to say: "that will make it run faster", you have to check it.
50 Rerun the code under control of the benchmarking or profiling modules, from the
51 first step above, and check that the new code executed the B<same task> in
52 I<less time>. Save your work and repeat...
54 =head1 GENERAL GUIDELINES
56 The critical thing when considering performance is to remember there is no such
57 thing as a C<Golden Bullet>, which is why there are no rules, only guidelines.
59 It is clear that inline code is going to be faster than subroutine or method
60 calls, because there is less overhead, but this approach has the disadvantage
61 of being less maintainable and comes at the cost of greater memory usage -
62 there is no such thing as a free lunch. If you are searching for an element in
63 a list, it can be more efficient to store the data in a hash structure, and
64 then simply look to see whether the key is defined, rather than to loop through
65 the entire array using grep() for instance. substr() may be (a lot) faster
66 than grep() but not as flexible, so you have another trade-off to access. Your
67 code may contain a line which takes 0.01 of a second to execute which if you
68 call it 1,000 times, quite likely in a program parsing even medium sized files
69 for instance, you already have a 10 second delay, in just one single code
70 location, and if you call that line 100,000 times, your entire program will
71 slow down to an unbearable crawl.
73 Using a subroutine as part of your sort is a powerful way to get exactly what
74 you want, but will usually be slower than the built-in I<alphabetic> C<cmp> and
75 I<numeric> C<E<lt>=E<gt>> sort operators. It is possible to make multiple
76 passes over your data, building indices to make the upcoming sort more
77 efficient, and to use what is known as the C<OM> (Orcish Maneuver) to cache the
78 sort keys in advance. The cache lookup, while a good idea, can itself be a
79 source of slowdown by enforcing a double pass over the data - once to setup the
80 cache, and once to sort the data. Using C<pack()> to extract the required sort
81 key into a consistent string can be an efficient way to build a single string
82 to compare, instead of using multiple sort keys, which makes it possible to use
83 the standard, written in C<c> and fast, perl C<sort()> function on the output,
84 and is the basis of the C<GRT> (Guttman Rossler Transform). Some string
85 combinations can slow the C<GRT> down, by just being too plain complex for its
88 For applications using database backends, the standard C<DBIx> namespace has
89 tries to help with keeping things nippy, not least because it tries to I<not>
90 query the database until the latest possible moment, but always read the docs
91 which come with your choice of libraries. Among the many issues facing
92 developers dealing with databases should remain aware of is to always use
93 C<SQL> placeholders and to consider pre-fetching data sets when this might
94 prove advantageous. Splitting up a large file by assigning multiple processes
95 to parsing a single file, using say C<POE>, C<threads> or C<fork> can also be a
96 useful way of optimizing your usage of the available C<CPU> resources, though
97 this technique is fraught with concurrency issues and demands high attention to
100 Every case has a specific application and one or more exceptions, and there is
101 no replacement for running a few tests and finding out which method works best
102 for your particular environment, this is why writing optimal code is not an
103 exact science, and why we love using Perl so much - TMTOWTDI.
107 Here are a few examples to demonstrate usage of Perl's benchmarking tools.
109 =head2 Assigning and Dereferencing Variables.
111 I'm sure most of us have seen code which looks like, (or worse than), this:
113 if ( $obj->{_ref}->{_myscore} >= $obj->{_ref}->{_yourscore} ) {
116 This sort of code can be a real eyesore to read, as well as being very
117 sensitive to typos, and it's much clearer to dereference the variable
118 explicitly. We're side-stepping the issue of working with object-oriented
119 programming techniques to encapsulate variable access via methods, only
120 accessible through an object. Here we're just discussing the technical
121 implementation of choice, and whether this has an effect on performance. We
122 can see whether this dereferencing operation, has any overhead by putting
123 comparative code in a file and running a C<Benchmark> test.
136 _myscore => '100 + 1',
137 _yourscore => '102 - 1',
143 my $x = $ref->{ref}->{_myscore} . $ref->{ref}->{_yourscore} ;
145 'dereference' => sub {
146 my $ref = $ref->{ref};
147 my $myscore = $ref->{_myscore};
148 my $yourscore = $ref->{_yourscore};
149 my $x = $myscore . $yourscore;
153 It's essential to run any timing measurements a sufficient number of times so
154 the numbers settle on a numerical average, otherwise each run will naturally
155 fluctuate due to variations in the environment, to reduce the effect of
156 contention for C<CPU> resources and network bandwidth for instance. Running
157 the above code for one million iterations, we can take a look at the report
158 output by the C<Benchmark> module, to see which approach is the most effective.
162 Benchmark: timing 1000000 iterations of dereference, direct...
163 dereference: 2 wallclock secs ( 1.59 usr + 0.00 sys = 1.59 CPU) @ 628930.82/s (n=1000000)
164 direct: 1 wallclock secs ( 1.20 usr + 0.00 sys = 1.20 CPU) @ 833333.33/s (n=1000000)
166 The difference is clear to see and the dereferencing approach is slower. While
167 it managed to execute an average of 628,930 times a second during our test, the
168 direct approach managed to run an additional 204,403 times, unfortunately.
169 Unfortunately, because there are many examples of code written using the
170 multiple layer direct variable access, and it's usually horrible. It is,
171 however, minusculy faster. The question remains whether the minute gain is
172 actually worth the eyestrain, or the loss of maintainability.
174 =head2 Search and replace or tr
176 If we have a string which needs to be modified, while a regex will almost
177 always be much more flexible, C<tr>, an oft underused tool, can still be a
178 useful. One scenario might be replace all vowels with another character. The
179 regex solution might look like this:
181 $str =~ s/[aeiou]/x/g
183 The C<tr> alternative might look like this:
185 $str =~ tr/aeiou/xxxxx/
187 We can put that into a test file which we can run to check which approach is
188 the fastest, using a global C<$STR> variable to assign to the C<my $str>
189 variable so as to avoid perl trying to optimize any of the work away by
190 noticing it's assigned only the once.
192 # regex-transliterate
201 my $STR = "$$-this and that";
203 timethese( 1000000, {
204 'sr' => sub { my $str = $STR; $str =~ s/[aeiou]/x/g; return $str; },
205 'tr' => sub { my $str = $STR; $str =~ tr/aeiou/xxxxx/; return $str; },
208 Running the code gives us our results:
210 $> perl regex-transliterate
212 Benchmark: timing 1000000 iterations of sr, tr...
213 sr: 2 wallclock secs ( 1.19 usr + 0.00 sys = 1.19 CPU) @ 840336.13/s (n=1000000)
214 tr: 0 wallclock secs ( 0.49 usr + 0.00 sys = 0.49 CPU) @ 2040816.33/s (n=1000000)
216 The C<tr> version is a clear winner. One solution is flexible, the other is
217 fast - and it's appropriately the programmer's choice which to use.
219 Check the C<Benchmark> docs for further useful techniques.
221 =head1 PROFILING TOOLS
223 A slightly larger piece of code will provide something on which a profiler can
224 produce more extensive reporting statistics. This example uses the simplistic
225 C<wordmatch> program which parses a given input file and spews out a short
226 report on the contents.
237 filewords - word analysis of input file
241 filewords -f inputfilename [-d]
245 This program parses the given filename, specified with C<-f>, and
246 displays a simple analysis of the words found therein. Use the C<-d>
247 switch to enable debugging messages.
257 my $result = GetOptions (
261 die("invalid args") unless $result;
263 unless ( -f $file ) {
264 die("Usage: $0 -f filename [-d]");
266 my $FH = FileHandle->new("< $file")
267 or die("unable to open file($file): $!");
274 foreach my $line ( @lines ) {
277 my @words = split(/ +/, $line);
278 my $i_words = scalar(@words);
279 $i_WORDS = $i_WORDS + $i_words;
280 debug("line: $i_LINES supplying $i_words words: @words");
282 foreach my $word ( @words ) {
284 $count{$i_LINES}{spec} += matches($i_word, $word,
286 $count{$i_LINES}{only} += matches($i_word, $word,
288 $count{$i_LINES}{cons} += matches($i_word, $word,
289 '^[(?i:bcdfghjklmnpqrstvwxyz)]+$');
290 $count{$i_LINES}{vows} += matches($i_word, $word,
292 $count{$i_LINES}{caps} += matches($i_word, $word,
297 print report( %count );
305 if ( $word =~ /($regex)/ ) {
309 debug( "word: $i_wd "
310 . ($has ? 'matches' : 'does not match')
311 . " chars: /$regex/");
320 foreach my $line ( keys %report ) {
321 foreach my $key ( keys %{ $report{$line} } ) {
322 $rep{$key} += $report{$line}{$key};
328 lines in file: $i_LINES
329 words in file: $i_WORDS
330 words with special (non-word) characters: $i_spec
331 words with only special (non-word) characters: $i_only
332 words with only consonants: $i_cons
333 words with only capital letters: $i_caps
334 words with only vowels: $i_vows
344 print STDERR "DBG: $message\n";
352 This venerable module has been the de-facto standard for Perl code profiling
353 for more than a decade, but has been replaced by a number of other modules
354 which have brought us back to the 21st century. Although you're recommended to
355 evaluate your tool from the several mentioned here and from the CPAN list at
356 the base of this document, (and currently L<Devel::NYTProf> seems to be the
357 weapon of choice - see below), we'll take a quick look at the output from
358 L<Devel::DProf> first, to set a baseline for Perl profiling tools. Run the
359 above program under the control of C<Devel::DProf> by using the C<-d> switch on
362 $> perl -d:DProf wordmatch -f perl5db.pl
364 <...multiple lines snipped...>
366 wordmatch report for perl5db.pl:
369 words with special (non-word) characters: 20480
370 words with only special (non-word) characters: 7790
371 words with only consonants: 4801
372 words with only capital letters: 1316
373 words with only vowels: 1701
375 C<Devel::DProf> produces a special file, called F<tmon.out> by default, and
376 this file is read by the C<dprofpp> program, which is already installed as part
377 of the C<Devel::DProf> distribution. If you call C<dprofpp> with no options,
378 it will read the F<tmon.out> file in the current directory and produce a human
379 readable statistics report of the run of your program. Note that this may take
384 Total Elapsed Time = 2.951677 Seconds
385 User+System Time = 2.871677 Seconds
387 %Time ExclSec CumulS #Calls sec/call Csec/c Name
388 102. 2.945 3.003 251215 0.0000 0.0000 main::matches
389 2.40 0.069 0.069 260643 0.0000 0.0000 main::debug
390 1.74 0.050 0.050 1 0.0500 0.0500 main::report
391 1.04 0.030 0.049 4 0.0075 0.0123 main::BEGIN
392 0.35 0.010 0.010 3 0.0033 0.0033 Exporter::as_heavy
393 0.35 0.010 0.010 7 0.0014 0.0014 IO::File::BEGIN
394 0.00 - -0.000 1 - - Getopt::Long::FindOption
395 0.00 - -0.000 1 - - Symbol::BEGIN
396 0.00 - -0.000 1 - - Fcntl::BEGIN
397 0.00 - -0.000 1 - - Fcntl::bootstrap
398 0.00 - -0.000 1 - - warnings::BEGIN
399 0.00 - -0.000 1 - - IO::bootstrap
400 0.00 - -0.000 1 - - Getopt::Long::ConfigDefaults
401 0.00 - -0.000 1 - - Getopt::Long::Configure
402 0.00 - -0.000 1 - - Symbol::gensym
404 C<dprofpp> will produce some quite detailed reporting on the activity of the
405 C<wordmatch> program. The wallclock, user and system, times are at the top of
406 the analysis, and after this are the main columns defining which define the
407 report. Check the C<dprofpp> docs for details of the many options it supports.
409 See also C<Apache::DProf> which hooks C<Devel::DProf> into C<mod_perl>.
411 =head2 Devel::Profiler
413 Let's take a look at the same program using a different profiler:
414 C<Devel::Profiler>, a drop-in Perl-only replacement for C<Devel::DProf>. The
415 usage is very slightly different in that instead of using the special C<-d:>
416 flag, you pull C<Devel::Profiler> in directly as a module using C<-M>.
418 $> perl -MDevel::Profiler wordmatch -f perl5db.pl
420 <...multiple lines snipped...>
422 wordmatch report for perl5db.pl:
425 words with special (non-word) characters: 20480
426 words with only special (non-word) characters: 7790
427 words with only consonants: 4801
428 words with only capital letters: 1316
429 words with only vowels: 1701
432 C<Devel::Profiler> generates a tmon.out file which is compatible with the
433 C<dprofpp> program, thus saving the construction of a dedicated statistics
434 reader program. C<dprofpp> usage is therefore identical to the above example.
438 Total Elapsed Time = 20.984 Seconds
439 User+System Time = 19.981 Seconds
441 %Time ExclSec CumulS #Calls sec/call Csec/c Name
442 49.0 9.792 14.509 251215 0.0000 0.0001 main::matches
443 24.4 4.887 4.887 260643 0.0000 0.0000 main::debug
444 0.25 0.049 0.049 1 0.0490 0.0490 main::report
445 0.00 0.000 0.000 1 0.0000 0.0000 Getopt::Long::GetOptions
446 0.00 0.000 0.000 2 0.0000 0.0000 Getopt::Long::ParseOptionSpec
447 0.00 0.000 0.000 1 0.0000 0.0000 Getopt::Long::FindOption
448 0.00 0.000 0.000 1 0.0000 0.0000 IO::File::new
449 0.00 0.000 0.000 1 0.0000 0.0000 IO::Handle::new
450 0.00 0.000 0.000 1 0.0000 0.0000 Symbol::gensym
451 0.00 0.000 0.000 1 0.0000 0.0000 IO::File::open
453 Interestingly we get slightly different results, which is mostly because the
454 algorithm which generates the report is different, even though the output file
455 format was allegedly identical. The elapsed, user and system times are clearly
456 showing the time it took for C<Devel::Profiler> to execute its own run, but
457 the column listings feel more accurate somehow than the ones we had earlier
458 from C<Devel::DProf>. The 102% figure has disappeared, for example. This is
459 where we have to use the tools at our disposal, and recognise their pros and
460 cons, before using them. Interestingly, the numbers of calls for each
461 subroutine are identical in the two reports, it's the percentages which differ.
462 As the author of C<Devel::Proviler> writes:
464 ...running HTML::Template's test suite under Devel::DProf shows
465 output() taking NO time but Devel::Profiler shows around 10% of the
466 time is in output(). I don't know which to trust but my gut tells me
467 something is wrong with Devel::DProf. HTML::Template::output() is a
468 big routine that's called for every test. Either way, something needs
473 See also C<Devel::Apache::Profiler> which hooks C<Devel::Profiler> into C<mod_perl>.
475 =head2 Devel::SmallProf
477 The C<Devel::SmallProf> profiler examines the runtime of your Perl program and
478 produces a line-by-line listing to show how many times each line was called,
479 and how long each line took to execute. It is called by supplying the familiar
480 C<-d> flag to Perl at runtime.
482 $> perl -d:SmallProf wordmatch -f perl5db.pl
484 <...multiple lines snipped...>
486 wordmatch report for perl5db.pl:
489 words with special (non-word) characters: 20480
490 words with only special (non-word) characters: 7790
491 words with only consonants: 4801
492 words with only capital letters: 1316
493 words with only vowels: 1701
495 C<Devel::SmallProf> writes it's output into a file called F<smallprof.out>, by
496 default. The format of the file looks like this:
498 <num> <time> <ctime> <line>:<text>
500 When the program has terminated, the output may be examined and sorted using
501 any standard text filtering utilities. Something like the following may be
504 $> cat smallprof.out | grep \d*: | sort -k3 | tac | head -n20
506 251215 1.65674 7.68000 75: if ( $word =~ /($regex)/ ) {
507 251215 0.03264 4.40000 79: debug("word: $i_wd ".($has ? 'matches' :
508 251215 0.02693 4.10000 81: return $has;
509 260643 0.02841 4.07000 128: if ( $debug ) {
510 260643 0.02601 4.04000 126: my $message = shift;
511 251215 0.02641 3.91000 73: my $has = 0;
512 251215 0.03311 3.71000 70: my $i_wd = shift;
513 251215 0.02699 3.69000 72: my $regex = shift;
514 251215 0.02766 3.68000 71: my $word = shift;
515 50243 0.59726 1.00000 59: $count{$i_LINES}{cons} =
516 50243 0.48175 0.92000 61: $count{$i_LINES}{spec} =
517 50243 0.00644 0.89000 56: my $i_cons = matches($i_word, $word,
518 50243 0.48837 0.88000 63: $count{$i_LINES}{caps} =
519 50243 0.00516 0.88000 58: my $i_caps = matches($i_word, $word, '^[(A-
520 50243 0.00631 0.81000 54: my $i_spec = matches($i_word, $word, '[^a-
521 50243 0.00496 0.80000 57: my $i_vows = matches($i_word, $word,
522 50243 0.00688 0.80000 53: $i_word++;
523 50243 0.48469 0.79000 62: $count{$i_LINES}{only} =
524 50243 0.48928 0.77000 60: $count{$i_LINES}{vows} =
525 50243 0.00683 0.75000 55: my $i_only = matches($i_word, $word, '^[^a-
527 You can immediately see a slightly different focus to the subroutine profiling
528 modules, and we start to see exactly which line of code is taking the most
529 time. That regex line is looking a bit suspicious, for example. Remember that
530 these tools are supposed to be used together, there is no single best way to
531 profile your code, you need to use the best tools for the job.
533 See also C<Apache::SmallProf> which hooks C<Devel::SmallProf> into C<mod_perl>.
535 =head2 Devel::FastProf
537 C<Devel::FastProf> is another Perl line profiler. This was written with a view
538 to getting a faster line profiler, than is possible with for example
539 C<Devel::SmallProf>, because it's written in C<C>. To use C<Devel::FastProf>,
540 supply the C<-d> argument to Perl:
542 $> perl -d:FastProf wordmatch -f perl5db.pl
544 <...multiple lines snipped...>
546 wordmatch report for perl5db.pl:
549 words with special (non-word) characters: 20480
550 words with only special (non-word) characters: 7790
551 words with only consonants: 4801
552 words with only capital letters: 1316
553 words with only vowels: 1701
555 C<Devel::FastProf> writes statistics to the file F<fastprof.out> in the current
556 directory. The output file, which can be specified, can be interpreted by using
557 the C<fprofpp> command-line program.
559 $> fprofpp | head -n20
561 # fprofpp output format is:
562 # filename:line time count: source
563 wordmatch:75 3.93338 251215: if ( $word =~ /($regex)/ ) {
564 wordmatch:79 1.77774 251215: debug("word: $i_wd ".($has ? 'matches' : 'does not match')." chars: /$regex/");
565 wordmatch:81 1.47604 251215: return $has;
566 wordmatch:126 1.43441 260643: my $message = shift;
567 wordmatch:128 1.42156 260643: if ( $debug ) {
568 wordmatch:70 1.36824 251215: my $i_wd = shift;
569 wordmatch:71 1.36739 251215: my $word = shift;
570 wordmatch:72 1.35939 251215: my $regex = shift;
572 Straightaway we can see that the number of times each line has been called is
573 identical to the C<Devel::SmallProf> output, and the sequence is only very
574 slightly different based on the ordering of the amount of time each line took
575 to execute, C<if ( $debug ) { > and C<my $message = shift;>, for example. The
576 differences in the actual times recorded might be in the algorithm used
577 internally, or it could be due to system resource limitations or contention.
579 See also the L<DBIx::Profile> which will profile database queries running
580 under the C<DBIx::*> namespace.
582 =head2 Devel::NYTProf
584 C<Devel::NYTProf> is the B<next generation> of Perl code profiler, fixing many
585 shortcomings in other tools and implementing many cool features. First of all it
586 can be used as either a I<line> profiler, a I<block> or a I<subroutine>
587 profiler, all at once. It can also use sub-microsecond (100ns) resolution on
588 systems which provide C<clock_gettime()>. It can be started and stopped even
589 by the program being profiled. It's a one-line entry to profile C<mod_perl>
590 applications. It's written in C<c> and is probably the fastest profiler
591 available for Perl. The list of coolness just goes on. Enough of that, let's
592 see how to it works - just use the familiar C<-d> switch to plug it in and run
595 $> perl -d:NYTProf wordmatch -f perl5db.pl
597 wordmatch report for perl5db.pl:
600 words with special (non-word) characters: 20480
601 words with only special (non-word) characters: 7790
602 words with only consonants: 4801
603 words with only capital letters: 1316
604 words with only vowels: 1701
606 C<NYTProf> will generate a report database into the file F<nytprof.out> by
607 default. Human readable reports can be generated from here by using the
608 supplied C<nytprofhtml> (HTML output) and C<nytprofcsv> (CSV output) programs.
609 We've used the Unix system C<html2text> utility to convert the
610 F<nytprof/index.html> file for convenience here.
612 $> html2text nytprof/index.html
614 Performance Profile Index
616 Run on Fri Sep 26 13:46:39 2008
617 Reported on Fri Sep 26 13:47:23 2008
619 Top 15 Subroutines -- ordered by exclusive time
620 |Calls |P |F |Inclusive|Exclusive|Subroutine |
621 | | | |Time |Time | |
622 |251215|5 |1 |13.09263 |10.47692 |main:: |matches |
623 |260642|2 |1 |2.71199 |2.71199 |main:: |debug |
624 |1 |1 |1 |0.21404 |0.21404 |main:: |report |
625 |2 |2 |2 |0.00511 |0.00511 |XSLoader:: |load (xsub) |
626 |14 |14|7 |0.00304 |0.00298 |Exporter:: |import |
627 |3 |1 |1 |0.00265 |0.00254 |Exporter:: |as_heavy |
628 |10 |10|4 |0.00140 |0.00140 |vars:: |import |
629 |13 |13|1 |0.00129 |0.00109 |constant:: |import |
630 |1 |1 |1 |0.00360 |0.00096 |FileHandle:: |import |
631 |3 |3 |3 |0.00086 |0.00074 |warnings::register::|import |
632 |9 |3 |1 |0.00036 |0.00036 |strict:: |bits |
633 |13 |13|13|0.00032 |0.00029 |strict:: |import |
634 |2 |2 |2 |0.00020 |0.00020 |warnings:: |import |
635 |2 |1 |1 |0.00020 |0.00020 |Getopt::Long:: |ParseOptionSpec|
636 |7 |7 |6 |0.00043 |0.00020 |strict:: |unimport |
638 For more information see the full list of 189 subroutines.
640 The first part of the report already shows the critical information regarding
641 which subroutines are using the most time. The next gives some statistics
642 about the source files profiled.
644 Source Code Files -- ordered by exclusive time then name
645 |Stmts |Exclusive|Avg. |Reports |Source File |
647 |2699761|15.66654 |6e-06 |line . block . sub|wordmatch |
648 |35 |0.02187 |0.00062|line . block . sub|IO/Handle.pm |
649 |274 |0.01525 |0.00006|line . block . sub|Getopt/Long.pm |
650 |20 |0.00585 |0.00029|line . block . sub|Fcntl.pm |
651 |128 |0.00340 |0.00003|line . block . sub|Exporter/Heavy.pm |
652 |42 |0.00332 |0.00008|line . block . sub|IO/File.pm |
653 |261 |0.00308 |0.00001|line . block . sub|Exporter.pm |
654 |323 |0.00248 |8e-06 |line . block . sub|constant.pm |
655 |12 |0.00246 |0.00021|line . block . sub|File/Spec/Unix.pm |
656 |191 |0.00240 |0.00001|line . block . sub|vars.pm |
657 |77 |0.00201 |0.00003|line . block . sub|FileHandle.pm |
658 |12 |0.00198 |0.00016|line . block . sub|Carp.pm |
659 |14 |0.00175 |0.00013|line . block . sub|Symbol.pm |
660 |15 |0.00130 |0.00009|line . block . sub|IO.pm |
661 |22 |0.00120 |0.00005|line . block . sub|IO/Seekable.pm |
662 |198 |0.00085 |4e-06 |line . block . sub|warnings/register.pm|
663 |114 |0.00080 |7e-06 |line . block . sub|strict.pm |
664 |47 |0.00068 |0.00001|line . block . sub|warnings.pm |
665 |27 |0.00054 |0.00002|line . block . sub|overload.pm |
666 |9 |0.00047 |0.00005|line . block . sub|SelectSaver.pm |
667 |13 |0.00045 |0.00003|line . block . sub|File/Spec.pm |
668 |2701595|15.73869 | |Total |
669 |128647 |0.74946 | |Average |
670 | |0.00201 |0.00003|Median |
671 | |0.00121 |0.00003|Deviation |
673 Report produced by the NYTProf 2.03 Perl profiler, developed by Tim Bunce and
676 At this point, if you're using the I<html> report, you can click through the
677 various links to bore down into each subroutine and each line of code. Because
678 we're using the text reporting here, and there's a whole directory full of
679 reports built for each source file, we'll just display a part of the
680 corresponding F<wordmatch-line.html> file, sufficient to give an idea of the
681 sort of output you can expect from this cool tool.
683 $> html2text nytprof/wordmatch-line.html
685 Performance Profile -- -block view-.-line view-.-sub view-
687 Run on Fri Sep 26 13:46:39 2008
688 Reported on Fri Sep 26 13:47:22 2008
692 Subroutines -- ordered by exclusive time
693 |Calls |P|F|Inclusive|Exclusive|Subroutine |
694 | | | |Time |Time | |
695 |251215|5|1|13.09263 |10.47692 |main::|matches|
696 |260642|2|1|2.71199 |2.71199 |main::|debug |
697 |1 |1|1|0.21404 |0.21404 |main::|report |
698 |0 |0|0|0 |0 |main::|BEGIN |
701 |Line|Stmts.|Exclusive|Avg. |Code |
703 |1 | | | |#!/usr/bin/perl |
705 | | | | |use strict; |
706 |3 |3 |0.00086 |0.00029|# spent 0.00003s making 1 calls to strict:: |
708 | | | | |use warnings; |
709 |4 |3 |0.01563 |0.00521|# spent 0.00012s making 1 calls to warnings:: |
712 |6 | | | |=head1 NAME |
714 |8 | | | |filewords - word analysis of input file |
716 |62 |1 |0.00445 |0.00445|print report( %count ); |
717 | | | | |# spent 0.21404s making 1 calls to main::report|
719 | | | | |# spent 23.56955s (10.47692+2.61571) within |
720 | | | | |main::matches which was called 251215 times, |
721 | | | | |avg 0.00005s/call: # 50243 times |
722 | | | | |(2.12134+0.51939s) at line 57 of wordmatch, avg|
723 | | | | |0.00005s/call # 50243 times (2.17735+0.54550s) |
724 |64 | | | |at line 56 of wordmatch, avg 0.00005s/call # |
725 | | | | |50243 times (2.10992+0.51797s) at line 58 of |
726 | | | | |wordmatch, avg 0.00005s/call # 50243 times |
727 | | | | |(2.12696+0.51598s) at line 55 of wordmatch, avg|
728 | | | | |0.00005s/call # 50243 times (1.94134+0.51687s) |
729 | | | | |at line 54 of wordmatch, avg 0.00005s/call |
730 | | | | |sub matches { |
733 | | | | |# spent 2.71199s within main::debug which was |
734 | | | | |called 260642 times, avg 0.00001s/call: # |
735 | | | | |251215 times (2.61571+0s) by main::matches at |
736 |103 | | | |line 74 of wordmatch, avg 0.00001s/call # 9427 |
737 | | | | |times (0.09628+0s) at line 50 of wordmatch, avg|
738 | | | | |0.00001s/call |
739 | | | | |sub debug { |
740 |104 |260642|0.58496 |2e-06 |my $message = shift; |
742 |106 |260642|1.09917 |4e-06 |if ( $debug ) { |
743 |107 | | | |print STDERR "DBG: $message\n"; |
747 |111 |1 |0.01501 |0.01501|exit 0; |
750 Oodles of very useful information in there - this seems to be the way forward.
752 See also C<Devel::NYTProf::Apache> which hooks C<Devel::NYTProf> into C<mod_perl>.
756 Perl modules are not the only tools a performance analyst has at their
757 disposal, system tools like C<time> should not be overlooked as the next
758 example shows, where we take a quick look at sorting. Many books, theses and
759 articles, have been written about efficient sorting algorithms, and this is not
760 the place to repeat such work, there's several good sorting modules which
761 deserve taking a look at too: C<Sort::Maker>, C<Sort::Key> spring to mind.
762 However, it's still possible to make some observations on certain Perl specific
763 interpretations on issues relating to sorting data sets and give an example or
764 two with regard to how sorting large data volumes can effect performance.
765 Firstly, an often overlooked point when sorting large amounts of data, one can
766 attempt to reduce the data set to be dealt with and in many cases C<grep()> can
767 be quite useful as a simple filter:
769 @data = sort grep { /$filter/ } @incoming
771 A command such as this can vastly reduce the volume of material to actually
772 sort through in the first place, and should not be too lightly disregarded
773 purely on the basis of its simplicity. The C<KISS> principle is too often
774 overlooked - the next example uses the simple system C<time> utility to
775 demonstrate. Let's take a look at an actual example of sorting the contents of
776 a large file, an apache logfile would do. This one has over a quarter of a
777 million lines, is 50M in size, and a snippet of it looks like this:
781 188.209-65-87.adsl-dyn.isp.belgacom.be - - [08/Feb/2007:12:57:16 +0000] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
782 188.209-65-87.adsl-dyn.isp.belgacom.be - - [08/Feb/2007:12:57:16 +0000] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
783 151.56.71.198 - - [08/Feb/2007:12:57:41 +0000] "GET /suse-on-vaio.html HTTP/1.1" 200 2858 "http://www.linux-on-laptops.com/sony.html" "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1"
784 151.56.71.198 - - [08/Feb/2007:12:57:42 +0000] "GET /data/css HTTP/1.1" 404 206 "http://www.rfi.net/suse-on-vaio.html" "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1"
785 151.56.71.198 - - [08/Feb/2007:12:57:43 +0000] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1"
786 217.113.68.60 - - [08/Feb/2007:13:02:15 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
787 217.113.68.60 - - [08/Feb/2007:13:02:16 +0000] "GET /data/css HTTP/1.1" 404 206 "http://www.rfi.net/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
788 debora.to.isac.cnr.it - - [08/Feb/2007:13:03:58 +0000] "GET /suse-on-vaio.html HTTP/1.1" 200 2858 "http://www.linux-on-laptops.com/sony.html" "Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.0 (like Gecko)"
789 debora.to.isac.cnr.it - - [08/Feb/2007:13:03:58 +0000] "GET /data/css HTTP/1.1" 404 206 "http://www.rfi.net/suse-on-vaio.html" "Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.0 (like Gecko)"
790 debora.to.isac.cnr.it - - [08/Feb/2007:13:03:58 +0000] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.0 (like Gecko)"
791 195.24.196.99 - - [08/Feb/2007:13:26:48 +0000] "GET / HTTP/1.0" 200 3309 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9"
792 195.24.196.99 - - [08/Feb/2007:13:26:58 +0000] "GET /data/css HTTP/1.0" 404 206 "http://www.rfi.net/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9"
793 195.24.196.99 - - [08/Feb/2007:13:26:59 +0000] "GET /favicon.ico HTTP/1.0" 404 209 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9"
794 crawl1.cosmixcorp.com - - [08/Feb/2007:13:27:57 +0000] "GET /robots.txt HTTP/1.0" 200 179 "-" "voyager/1.0"
795 crawl1.cosmixcorp.com - - [08/Feb/2007:13:28:25 +0000] "GET /links.html HTTP/1.0" 200 3413 "-" "voyager/1.0"
796 fhm226.internetdsl.tpnet.pl - - [08/Feb/2007:13:37:32 +0000] "GET /suse-on-vaio.html HTTP/1.1" 200 2858 "http://www.linux-on-laptops.com/sony.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
797 fhm226.internetdsl.tpnet.pl - - [08/Feb/2007:13:37:34 +0000] "GET /data/css HTTP/1.1" 404 206 "http://www.rfi.net/suse-on-vaio.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
798 80.247.140.134 - - [08/Feb/2007:13:57:35 +0000] "GET / HTTP/1.1" 200 3309 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
799 80.247.140.134 - - [08/Feb/2007:13:57:37 +0000] "GET /data/css HTTP/1.1" 404 206 "http://www.rfi.net" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
800 pop.compuscan.co.za - - [08/Feb/2007:14:10:43 +0000] "GET / HTTP/1.1" 200 3309 "-" "www.clamav.net"
801 livebot-207-46-98-57.search.live.com - - [08/Feb/2007:14:12:04 +0000] "GET /robots.txt HTTP/1.0" 200 179 "-" "msnbot/1.0 (+http://search.msn.com/msnbot.htm)"
802 livebot-207-46-98-57.search.live.com - - [08/Feb/2007:14:12:04 +0000] "GET /html/oracle.html HTTP/1.0" 404 214 "-" "msnbot/1.0 (+http://search.msn.com/msnbot.htm)"
803 dslb-088-064-005-154.pools.arcor-ip.net - - [08/Feb/2007:14:12:15 +0000] "GET / HTTP/1.1" 200 3309 "-" "www.clamav.net"
804 196.201.92.41 - - [08/Feb/2007:14:15:01 +0000] "GET / HTTP/1.1" 200 3309 "-" "MOT-L7/08.B7.DCR MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1"
806 The specific task here is to sort the 286,525 lines of this file by Response
807 Code, Query, Browser, Referring Url, and lastly Date. One solution might be to
808 use the following code, which iterates over the files given on the
838 my @chunks = split(/ +/, $line);
845 push(@data, [$ip, $date, $query, $status, $browser, $line]);
861 foreach my $data ( @sorted ) {
867 When running this program, redirect C<STDOUT> so it is possible to check the
868 output is correct from following test runs and use the system C<time> utility
869 to check the overall runtime.
871 $> time ./sort-apache-log logfile > out-sort
877 The program took just over 17 wallclock seconds to run. Note the different
878 values C<time> outputs, it's important to always use the same one, and to not
879 confuse what each one means.
883 =item Elapsed Real Time
885 The overall, or wallclock, time between when C<time> was called, and when it
886 terminates. The elapsed time includes both user and system times, and time
887 spent waiting for other users and processes on the system. Inevitably, this is
888 the most approximate of the measurements given.
892 The user time is the amount of time the entire process spent on behalf of the
893 user on this system executing this program.
895 =item System CPU Time
897 The system time is the amount of time the kernel itself spent executing
898 routines, or system calls, on behalf of this process user.
902 Running this same process as a C<Schwarzian Transform> it is possible to
903 eliminate the input and output arrays for storing all the data, and work on the
904 input directly as it arrives too. Otherwise, the code looks fairly similar:
906 # sort-apache-log-schwarzian
946 Run the new code against the same logfile, as above, to check the new time.
948 $> time ./sort-apache-log-schwarzian logfile > out-schwarz
954 The time has been cut in half, which is a respectable speed improvement by any
955 standard. Naturally, it is important to check the output is consistent with
956 the first program run, this is where the Unix system C<cksum> utility comes in.
958 $> cksum out-sort out-schwarz
959 3044173777 52029194 out-sort
960 3044173777 52029194 out-schwarz
962 BTW. Beware too of pressure from managers who see you speed a program up by 50%
963 of the runtime once, only to get a request one month later to do the same again
964 (true story) - you'll just have to point out you're only human, even if you are a
965 Perl programmer, and you'll see what you can do...
969 An essential part of any good development process is appropriate error handling
970 with appropriately informative messages, however there exists a school of
971 thought which suggests that log files should be I<chatty>, as if the chain of
972 unbroken output somehow ensures the survival of the program. If speed is in
973 any way an issue, this approach is wrong.
975 A common sight is code which looks something like this:
977 logger->debug( "A logging message via process-id: $$ INC: "
980 The problem is that this code will always be parsed and executed, even when the
981 debug level set in the logging configuration file is zero. Once the debug()
982 subroutine has been entered, and the internal C<$debug> variable confirmed to
983 be zero, for example, the message which has been sent in will be discarded and
984 the program will continue. In the example given though, the C<\%INC> hash will
985 already have been dumped, and the message string constructed, all of which work
986 could be bypassed by a debug variable at the statement level, like this:
988 logger->debug( "A logging message via process-id: $$ INC: "
989 . Dumper(\%INC) ) if $DEBUG;
991 This effect can be demonstrated by setting up a test script with both forms,
992 including a C<debug()> subroutine to emulate typical C<logger()> functionality.
1009 print "DEBUG: $msg\n";
1015 debug( "A $0 logging message via process-id: $$" . Dumper(\%INC) )
1018 debug( "A $0 logging message via process-id: $$" . Dumper(\%INC) ) if $DEBUG
1022 Let's see what C<Benchmark> makes of this:
1025 Benchmark: timing 100000 iterations of constant, sub...
1026 ifdebug: 0 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU) @ 10000000.00/s (n=100000)
1027 (warning: too few iterations for a reliable count)
1028 debug: 14 wallclock secs (13.18 usr + 0.04 sys = 13.22 CPU) @ 7564.30/s (n=100000)
1030 In the one case the code, which does exactly the same thing as far as
1031 outputting any debugging information is concerned, in other words nothing,
1032 takes 14 seconds, and in the other case the code takes one hundredth of a
1033 second. Looks fairly definitive. Use a C<$DEBUG> variable BEFORE you call the
1034 subroutine, rather than relying on the smart functionality inside it.
1036 =head2 Logging if DEBUG (constant)
1038 It's possible to take the previous idea a little further, by using a compile
1039 time C<DEBUG> constant.
1057 print "DEBUG: $msg\n";
1063 debug( "A $0 logging message via process-id: $$" . Dumper(\%INC) )
1066 debug( "A $0 logging message via process-id: $$" . Dumper(\%INC) ) if DEBUG
1070 Running this program produces the following output:
1072 $> perl ifdebug-constant
1073 Benchmark: timing 100000 iterations of constant, sub...
1074 constant: 0 wallclock secs (-0.00 usr + 0.00 sys = -0.00 CPU) @ -7205759403792793600000.00/s (n=100000)
1075 (warning: too few iterations for a reliable count)
1076 sub: 14 wallclock secs (13.09 usr + 0.00 sys = 13.09 CPU) @ 7639.42/s (n=100000)
1078 The C<DEBUG> constant wipes the floor with even the C<$debug> variable,
1079 clocking in at minus zero seconds, and generates a "warning: too few iterations
1080 for a reliable count" message into the bargain. To see what is really going
1081 on, and why we had too few iterations when we thought we asked for 100000, we
1082 can use the very useful C<B::Deparse> to inspect the new code:
1084 $> perl -MO=Deparse ifdebug-constant
1088 use constant ('DEBUG', 0);
1096 timethese(100000, {'sub', sub {
1097 debug "A $0 logging message via process-id: $$" . Dumper(\%INC);
1103 ifdebug-constant syntax OK
1105 The output shows the constant() subroutine we're testing being replaced with
1106 the value of the C<DEBUG> constant: zero. The line to be tested has been
1107 completely optimized away, and you can't get much more efficient than that.
1111 This document has provided several way to go about identifying hot-spots, and
1112 checking whether any modifications have improved the runtime of the code.
1114 As a final thought, remember that it's not (at the time of writing) possible to
1115 produce a useful program which will run in zero or negative time and this basic
1116 principle can be written as: I<useful programs are slow> by their very
1117 definition. It is of course possible to write a nearly instantaneous program,
1118 but it's not going to do very much, here's a very efficient one:
1122 Optimizing that any further is a job for C<p5p>.
1126 Further reading can be found using the modules and links below.
1130 For example: C<perldoc -f sort>.
1134 L<perlfork>, L<perlfunc>, L<perlretut>, L<perlthrtut>.
1144 It's not possible to individually showcase all the performance related code for
1145 Perl here, naturally, but here's a short list of modules from the CPAN which
1146 deserve further attention.
1158 Devel::NYTProf::Apache
1164 POE::Devel::Profiler
1170 Very useful online reference material:
1172 http://www.ccl4.org/~nick/P/Fast_Enough/
1174 http://www-128.ibm.com/developerworks/library/l-optperl.html
1176 http://perlbuzz.com/2007/11/bind-output-variables-in-dbi-for-speed-and-safety.html
1178 http://en.wikipedia.org/wiki/Performance_analysis
1180 http://apache.perl.org/docs/1.0/guide/performance.html
1182 http://perlgolf.sourceforge.net/
1184 http://www.sysarch.com/Perl/sort_paper.html
1188 Richard Foley <richard.foley@rfi.net> Copyright (c) 2008