Eric Lippert has written about performance at various times, and he notes that performance isn’t interesting in the abstract; it’s interesting as a measure of how close you are to your particular goal. He also notes that if you’re going to optimize – ie, worry about speed – not only should you know what you’re shooting for (“how slow is good enough?”), but you should also start by measuring, and then fixing the things that are the slowest. As has been pointed, the execution speed of any given lines of code is probably nothing in comparison to I/O speed, wire speed for Web pages, database speed, interacting with OMs/DOMs, and the drag effect of one’s dumb algorithms.
It’s also been noted, albeit less directly, that the choice of a language involves many factors, and performance is just one, and probably pretty low on the list. Ease of development, deployment, maintenance, and appropriateness to the problem (no one is programming DHTML in C++, for example) probably count for a lot more. It’s hard to imagine a situation in which a group of programmers sits down with a chart like this one and uses that to decide what language to code in. I suspect the real benefit of these types of comparisons is to enable people to say “Whew, I’m glad to see that my language isn’t the slowest one.”