The Day Performance Didn't Matter Any More
OSNews published a nine-language performance roundup in early 2004. The results are summarized here:
It's not a very practical benchmark, but it does tell us a few things. It's no surprise that C++ is at the head of the pack. But the others aren't terribly far behind. What I find really interesting, though, is how most of the languages clump together in the middle. There's no significant performance difference between Java and .NET if you throw out the weirdly anomalous trig results.
Interpreted languages tend to exact significant performance penalties because they must process each programming-language instruction before creating and executing machine code. In the performance benchmarking I performed for this chapter and chapter 26, I observed these approximate relationships in performance among different languages:
Language Type of Language Execution Time Relative to C++ C++ Compiled 1:1 Visual Basic Compiled 1:1 C# Compiled 1:1 Java Byte code 1.5:1 PHP Interpreted > 100:1 Python Interpreted > 100:1
Clearly, the performance penalty for interpreted languages is extreme. How extreme? If you have to ask, you probably can't afford it.
One of the biggest stigmas for early Visual Basic developers was that our code wasn't compiled. It was interpreted. Interpreted executables were yet another reason so-called "professional" developers didn't take VB seriously. It was too slow. This finally changed when we got compiled executables in 1997 with VB 5.
|AMD 1900+||1.6 GHz||12.25 sec|
|P4 Mobile||2.2 GHz||15.48 sec|
|P4 Celeron||1.4 GHz||17.43 sec|