The Alioth benchmarks do a really bad job of capturing the reality of language-related performance issues. The choice of specified algorithm is going to dominat

The Alioth benchmarks do a really bad job of capturing the reality of language-related performance issues. The choice of specified algorithm is going to dominate all other concerns in their benchmark, and that's not the sort of problem people face in the real world, perhaps out of rarefied HPC circles where benchmarks on one quad-core machine aren't relevant to anything. Performance handling in high level languages is more about knowing where the landmines are (total heap usage in GCed languages, various troublesome malloc()s, weird caches in dynamic languages...) and trying to figure out as quickly and cheaply as possible if the program you're planning on writing is going to hit them, and how much it's going to cost to mitigate it. It's not relevant if the actual runtime overhead of the problem is 5% or 1000x, the end product is either fast enough or it isn't, and the workaround is either viable or it isn't. Trying to protect yourself from this by picking the fastest language in a shootout isn't going to work because the perfect, gotcha-free language hasn't been invented yet. There are sound performance reasons to avoid any language, not just Perl.