What I get from skimming this article, it's just obsessing around premature optimization and small techniques to shave off "hundreds of microseconds or even whole seconds" from the runtime of programs. It doesn't mention Benchmark.pm, it does mention the profiler only in passing, and it doesn't mention the fact that optimizing/changing your algorithm to a better suited algorithm will most likely give a much bigger gain than any string concatenation optimization. The author mentions "compiling to C" via the perlcc backend as a viable option without telling the limits of this process and what the magic "compile your Perl to C" bullet actually will accomplish.

The one article about hardcore optimization of Perl code is When Perl is not quite fast enough by Nicholas Clark, and the IBM article doesn't go that way.

I am not really fond of these drive-by article spammings by the IBM Developerworks, and I'd prefer if IBM Developerworks offered a subscriber method so that the folks interested in the articles can be notified without "Perl News" also being spammed by this.

Update: On second reading, the author mentions what perlcc does. I still wonder what the sense is, at it only reduces startup time, which is negligible for long-running processes.
Added link to Nicholas Clarks "When Perl is not quite fast enough" talk

I'll also recommend Introduction to Code Turning from Code Complete 2. It's talking about C, but the principles are generic.

I didn't like that article a bit. If you want to improve the performance of your Perl program Perl Monks is a much better resource. If I recall correct there has been nodes about this before. (Update: or see When Perl is not quite fast enough as Corion pointed out.)

By the way, in this example, an even quicker way of producing a string that repeats the alphabet 999,999 times would be to use:

$concat = 999999 x 'abcdefghijklmnopqrstuvwxyz';
[download]

It must be rather embarrassing to make this obvious mistake that no one that writes an article about Perl should make.

A bit further down the article I read "Better still, in a simple calculation like this one or for any straightforward loop work, use map:", and then the author uses map BLOCK in void context instead of a for loop. Overlooking style issues it's still not a very good advice to me:

use Benchmark 'cmpthese';
use strict;
use warnings;

my @stuff = 1 .. 20000;

cmpthese(-3, {
    'for EXPR' => sub {
        my $a = 0;
        ++$a for @stuff;
    },
    'for BLOCK' => sub {
        my $a = 0;
        for (@stuff) { ++$a }
    },
    'map BLOCK' => sub {
        my $a = 0;
        map { ++$a  } @stuff;
    },
    'map EXPR' => sub {
        my $a = 0;
        map ++$a, @stuff;
    },
});
__END__
            Rate map BLOCK  map EXPR for BLOCK  for EXPR
map BLOCK 50.4/s        --       -4%      -44%      -49%
map EXPR  52.3/s        4%        --      -42%      -47%
for BLOCK 89.9/s       78%       72%        --       -9%
for EXPR  98.6/s       96%       89%       10%        --

This is perl, v5.8.0 built for MSWin32-x86-multi-thread
[download]

ihb

Try reading right at the bottom, at least, where it says 'Rate this article' .. Maybe we should..

C.

Also I'm glad that IBM is putting out articles discussing the workings of Perl, so I wouldn't go there to downvote it. Any article which induces "Perl thoughts" is good. :-)

IBM publishes some fine free resources. I hope they keep doing it.

Some of the little things we should watch out for are correctness and completeness, especially from someone who has written Debugging Perl.

Factual errors and omissions are embarassing. I'm sure he didn't make them on purpose, which makes downvoting and including constructive comments all the more important. Nobody learns from mistakes they aren't aware they've made.

-- Rocco Caputo - http://poe.perl.org/