The myth of Java's slowness

Twice in the past week, c.l.j.p has seen two claims (actually, the same
one repeated twice) that "Java is slower than C." Outside of that, I am
continually pelted with complaints that "Java is so slow!" One example:

"Java is slow."
"Yes it is."
"Okay then, prove to me that it's slow."
"In the USACO [ an algorithmic programming competition ], the Java time
is scaled by a factor of 1.5 to be competitive."

The USACO problems are extreme:
* The time for a C program to run is 1 second.
   Java is slow in the early part of its lifecycle; compare the same
metrics an hour or two into a program and the Hotspot optimizer will
make a noticeable difference.
* I believe that C is compiled with -O2.
   Sun used to (still does?) provide an option to optimize Java code;
this was taken out because metering determined that the Hotspot
optimizer works better on unoptimized code.
* Problems are heavily IO-dependent.
   This problem with metering has been explained in the other threads; I
am not going to repeat for the umpteen-th time.

A clearer example of what's going on here:
Planes are more efficient than rail, because a plane takes less time to
go between San Francisco and Washington, D.C. than a train would.

Obviously, this measure of "efficiency" is biased towards planes; I can
just as well bias it towards trains:
Trains is more efficient because it would take one train less time to
carry 10K tons of coal than a plane (the plane would have to go back and
forth over and over again; the train makes one trip).

Clearly, this shows the different design philosophies of air travel and
rail travel: air is optimized for high speed, whereas rail is optimized
for high capacity. Specifically metering one of these characteristics
gives heavily skewed results.

And that is why Java appears to be slow: people feed it problems
unwittingly optimized for native code (a combination of insufficient
teaching and misguided expectations). Java's full power comes in its
ability to easily achieve cross-platform effects. A Java fighter game
would have not only compatible source code, but compatible binaries for
both a Windows Vista dual-core machine as well as a Fedora Core 7 Linux
machine running on an AMD-64 chip. C cannot even use the same source
code, modulo complex configuration routines: an `int *' is a different
size on a 32-bit than a 64-bit machine.

Other areas of prowess are:
* Working across several regions of Unicode: C code needs to be
carefully handled to accept Japanese hiragana and Arabic characters at
the same time.
* Multithreading. Java has limited built-in multithread support; C code
does not.
* UI. Java provides a cross-platform UI set; C code does not.
* Dynamic method dispatch and runtime type information. C provides
neither without it having to be explicitly piped in; C++'s RTTI is, to
say the least, somewhat problematic.
* Memory management. C requires manual memory management, which makes it
easy to have poor memory benchmarks. Having some form of garbage
collection provided is becoming increasingly popular; Java has garbage
collection built-in (and improved for over a decade).

If I came up with a "benchmark" that showed that Java was the best in
handling multithreaded UI support using dynamic method dispatch that had
to handle Unicode properly, where the metrics were measured after the
programs had been running for a month, would you be surprised? Would you
cry foul that the "benchmark" was biased?

Just because C can print 1,000,000 lines of output 10 times faster than
Java doesn't mean that Java is slow. It just means that Java can't print
1,000,000 lines of output very quickly.

Measure the speed of C and of Java under most normal programs, and
you'll find that the difference between the two languages speed-wise is
negligible.

Please, don't give me another example of an esoteric, abnormal program
that no developer would ever include in one of his programs and use that
result to "prove" that Java is slow. I'll only respond by using another
similar program to "prove" that C or FORTRAN or PASCAL or whatever is slow.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth