[FONT=verdana, helvetica, arial, sans-serif]
Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled). [/FONT] [FONT=verdana, helvetica, arial, sans-serif]
Nevertheless, the idea that "java is slow" is widely believed. Why this is so is perhaps the most interesting aspect of this article. [/FONT]
[FONT=verdana, helvetica, arial, sans-serif]
Let's look at several possible reasons: [/FONT]
- [FONT=verdana, helvetica, arial, sans-serif]
[*]Java circa 1995 was slow. The first incarnations of java did not java a JIT compiler, and hence were bytecode interpreted (like Python for example). JIT compilers appeared in JVMs from Microsoft, Symantec, and in Sun's java1.2. This explanation is implausible. Most "computer folk" are able to rattle off the exact speed in GHz of the latest processors, and they track this information as it changes each month (and have done so for years). Yet this explanation asks us to believe that they are not able to remember that a single and rather important language speed change occurred in 1996.
[*] Java can be slow still. For example, programs written with the thread-safe Vector class are necessarily slower (on a single processor at least) than those written with the equivalent thread-unsafe ArrayList class. This explanation is equally unsatisfying, because C++ and other languages have similar "abstraction penalties". For example, The Kernighan and Pike book The Practice of Programming has a table with the following entries, describing the performance of several implementations of a text processing program:
Version400 MHz PII C 0.30 sec C++/STL/deque 11.2 sec C++/STL/list 1.5 sec Another evidently well known problem in C++ is the overhead of returning an object from a function (several unnecessary object create/copy/destruct cycles are involved).
[*]Java program startup is slow. As a java program starts, it unzips the java libraries and compiles parts of itself, so an interactive program can be sluggish for the first couple seconds of use. This approaches being a reasonable explanation for the speed myth. But while it might explain user's impressions, it does not explain why many programmers (who can easily understand the idea of an interpreted program being compiled) share the belief.
[/FONT]
[FONT=verdana, helvetica, arial, sans-serif]
Two of the most interesting observations regarding this issue are that: [/FONT]
- [FONT=verdana, helvetica, arial, sans-serif]
[*] there is a similar "garbage collection is slow" myth that persists despite decades of evidence to the contrary, and
[*] that in web flame wars, people are happy to discuss their speed impressions for many pages without ever referring to actual data.[/FONT]
[FONT=verdana, helvetica, arial, sans-serif]
Together these suggest that it is possible that no amount of data will alter peoples' beliefs, and that in actuality these "speed beliefs" probably have little to do with java, garbage collection, or the otherwise stated subject. Our answer probably lies somewhere in sociology or psychology. Programmers, despite their professed appreciation of logical thought, are not immune to a kind of mythology, though these particular "myths" are arbitrary and relatively harmless.
