The other thing is that Perl's built in data structure primitives have somehow hit a magical balance between performance, ease of use and power. Once you get used to the syntax, arbitrarily composing complex data structures is super-easy and they usually perform extremely well.
I think what's surprising is how snappy the language feels in aggregate, even if it benchmarks fairly slow. From execution to runtime, it just feels snappy and I think that may give it a false sense of performance while modern Java and C++ etc. really are faster, they have a clunky feel and lots of the user-facing things seem kind of creaky.
One other problem is that it's really easy to write really slow code in other languages, but even if you only do things mildly "the Perl way" it'll still run reasonably quick.
To this day, I'm still amazed at how many little Perl prototype projects I've written that outperformed their compiled rewrite cousins for months until lots of time was spent specifically tuning that rewritten code.
edit sorry for words I'm beer-posting tonight
http://benchmarksgame.alioth.debian.org/u32/which-programs-a...
Perl is solidly in the lowest tier of serious language performance, and that result is quite robust no matter how you query that site, and correlates to my personal experiences as well.
Perl isn't alone... it's joined by many of its 1990s-style dynamic scripting language buddies with very similar performance. And of course many fine programs are written in them nevertheless, so I don't mean this as a criticism... in fact if you read this as a "criticism" that needs to be "rebutted" in some sense you're entirely missing my point. I really shouldn't have to "qualify" this to fend off the obvious replies, but I've been around enough to know I do. But, it's true that a serious professional should be aware that Perl is in the slowest executing set of languages, and it is very possible for the difference to be significant for you in many commonly-occurring tasks.
You know, the picture becomes to come into focus to me. I suspect due to the prevalence of the saying "Languages don't have performance, only implementations do" and people constantly slagging on benchmarks without thought, simply reflexively, and probably helped by a healthy dose of both fanboyism and instinctive revulsion to fanboyism, programmers are apparently nearly completely incapable of having a reasonable discussion about which languages are faster than other, at what tasks, under what circumstances.
Well, that's a pity, because there is such a discussion to be had, and a lot of people are getting hurt because of their inability to get good information on this topic, and consequently making perfectly-avoidable bad decisions. Absolute statements are hard to come by, sure, but there are engineeringly-useful guidelines that you can discover if you examine the problem space.
I try to imagine a discussion between carpenters about chisels, saws or hammers and each having a favourite brand that they'd defend to the death in order to avoid an objective discussion about what the good and bad properties of each tool are.
After all, programming languages are just tools. What really matters is the applications you create with them, and that people will find your application useful and use it with pleasure.
Where there is choice people will complain about the choices of others.
Up to that point it is just your preference.
Ironically, you're being prickly in exactly the wrong direction. Perl is totally a serious language. I do most of my work in it, in fact. I qualify it with "serious language" because when I say it's one of the slowest serious languages, it's no fair to counter that by pointing out somebody's hobby implementation of Lispcheme that's a hundred time slower.
"In its class of languages Perl is one of the fastest."
Well... I suppose... since essentially all original C-interpreter implementations of the 1990s-style dynamic scripting languages have performance within about 20% of each other, that's not false... but the marketing-style implication that Perl is the fastest certainly is false. (Also LuaJIT is way faster, but does "compromise" relative to some Perl features to get there.) Drop the "C-interpreter" clause and Perl's in real trouble... Javascript isn't the C-speed language it sometimes gets presented as but JIT'ed JS really will handily beat Perl, and PyPy is... weirdly complicated from a performance perspective.
The point is still that talking about Perl as a perfomant language on almost any measure is... very weird. It's not. It's possible to name several serious languages which are as slow, but not one that clearly slower.
Using perl, you can not win speed benchmarks, but a C program significantly faster than the "normal" perl program, needs much much more development time.
I have already encountered a C project that was rewritten in perl because it was a maintenance nightmare. The client was very surprised by the performance increase.
I do not know what are your "commonly-occuring" tasks, but in my experience, perl performance was never the bottleneck.
You have to remember this idea comes from the late 90s when Java was slow as a dog, and Perl solidly cleaned the floor with other scripting languages like Python, Tcl, (was Ruby even known then?).
Perl even outpaced C++ for I/O related stuff due to the way Perl buffered input (or maybe the way C++ streams were so badly implemented). Of course a clean slate implement in C++ that avoided...well C++...and used mostly C style code would have cleaned the floor with Perl...but that was the state of C++ in the 90s.
Yeah...Perl had its heyday.
Perl has a lot of built-in functions, keywords, and operators. It's also a bytecode-compiled language (yeah, Perl is compiled when you run it, the compiler is just so fast you don't notice it.) But a lot of those built-ins don't compile to the bytecode equivalent of machine code for a VM like you might expect; they compile to a single instruction that's got an optimized implementation written in C. When you write idiomatic code, you tend to use built-ins in a way that allows those optimized instructions to be used, which gives you near-C level performance.
For example, if you want to loop over every member of a list, perform an operation on each member, and produce a new list based on the results of those operations, you could use a 'for' loop for that. But if you do than the Perl compiler needs to produce bytecode that mirrors the generic for loop and the full code in the body of the loop, pretty much as you wrote it. The compiler can't make any assumptions about the intended behavior. If you instead use the 'map' keyword, the compiler knows that you're transforming one list into another by running a bit of code on each member of the list, and it'll produce much more optimized code to do that.
It's kind of ironic. You can write 'C' style code in Perl but you won't get C-like performance that way, you'll get Perl-like performance. But if you write 'Perl' style code instead, you'll get C-like performance.
But you're right, Perl's implementation of this strategy isn't like classic Pascal or modern Java's implementations. But that doesn't alter my point; writing idiomatic Perl gives you a smaller AST with symbols that execute optimized code.
You're also right about Perl not having C-like performance for anything computational, because there you're dealing with Perl's data types, which are powerful and flexible but not efficient, as the article describes. My point was more about looping, set operations, string manipulation, conditional statements, and data structures. Perl has both efficient and inefficent ways to handle all of those, and it pays to learn to use the efficient expressions.
It even seems from those benchmarks you posted Perl did quite well in the reverse complement and regex DNA tests, as I would have expected.