Conclusions: Why is "Java is Slow" so Popular? 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).
Nevertheless, the idea that "java is slow" is widely believed. Why this is so is perhaps the most interesting aspect of this article.
Let's look at several possible reasons:
# 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:
*
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.
Two of the most interesting observations regarding this issue are that:
1. there is a similar "garbage collection is slow" myth that persists despite decades of evidence to the contrary, and 2. that in web flame wars, people are happy to discuss their speed impressions for many pages without ever referring to actual data.
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. Acknowledgements Ian Rogers and Curt Fischer clarified some points. References
[1] K. Reinholtz, Java will be faster than C++, ACM Sigplan Notices, 35(2): 25-28 Feb 2000.
[2] Benjamin Zorn, The Measured Cost of Conservative Garbage Collection Software - Practice and Experience 23(7): 733-756, 1992.
[3] Linux Number Crunching: Languages and Tools, referenced on slashdot.org
[4] Christopher W. Cowell-Shah, Nine Language Performance Round-up: Benchmarking Math & File I/O, appeared at OSnews.com, Jan. 2004.
[5] E. Schanzer, Performance Considerations for Run-Time Technologies in the .NET Framework, Microsoft Developer Network article.
554 名前：デフォルトの名無しさん [04/10/17 23:42:22]
漏れら極悪非道のageブラザーズ！ 今日もネタもないのにageてやるからな！ ￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ∧＿∧ ∧＿∧ age （・∀・∩）（∩・∀・） age （つ 丿 （ ⊂） age （ ヽノ ヽ/ ） age し（＿） （＿）Ｊ
Bindenlicht is a Java(tm) binding for the Irrlicht Engine, bringing a high quality open source 3D engine to the Java(tm) platform. sourceforge.net/projects/bindenlicht/
jirr.sourceforge.net, the java port of the Irrlicht Engine created by Stefan Dingfelder jirr.sourceforge.net/
