I once moved a major processing step from the database to C++. Execution time went from an estimated 1 week to a measured 5 minutes.

Why was the difference that big?

The fastest path to get a piece of data in the database is to do a binary search on an index that tells you what row in the table has your data, and what page of memory it is in. You then go to that page in memory, locate the row, parse it, and pull out the information of interest. All of this is controlled by instructions in some sort of microcode.

The equivalent data path is C++ was, "follow a pointer". Furthermore the C++ representation of the data was so much more compact that I was frequently managing to stay inside of CPU caches, versus the database approach where I was fighting to stay within RAM limitations.

Sometimes performance really, really does matter. (This is a rare circumstance.)

As for JavaScript, the reason that it beats everything else is that there is serious corporate muscle (eg Google and Apple) behind optimizing it as much as possible.

In my opinion each language is a tool and all have their place. Knowing what each can and cannot do is more important than which is faster. It also comes down to preference as well. If you are use to using PHP, then continue to use it. Would you use PHP for system admin tasks? No, you would use python or ruby.

Can't we all just get along and agree to stop bashing languages when comparing them to each other?

Sometimes. If your app is network/memory/disk bound, no. If it is CPU bound, yes. That's why web apps are in Python/Ruby, and games are in C++/C#.

Also, Ruby/Python/interpreted language performances are within a magnitude of each other so they're effectively equivalent.

I think this is just leftover annoyances from pre 1.9 mri perfomance is all.

As to compiling ruby to c, maybe, as long as its not eval()'ing ruby code. But rubinius+llvm+its jit would be the closest to what you're talking about. That or jruby too.