Hi all, It's said that Java is slower than other languages. I found that that one reason is that, when running or when one object is requested, JVM loads this object into memory and keep it there until garbage colletion after finish this request. And another is that it processes multi threads at the same time, so it's cost a lot memory useage. Is it true?. Would you please give me some more reason about that? Thanks a lot.
I'm not sure what study you were reading, but the one linked by William Brogden above shows that Java 1.4.2 either beat or compared very favorably to both C++, Visual C++, as well as C# .Net. The only area it lagged behind in was in calling trigonometric functions, but the author of the study himself admited he wasn't sure if there was a better way to call the functions than the methods he used.
Read the study again, and keep in mind that SMALLER numbers are better.
Java is indeed slower than some languages. It's also faster than some others.
It's also both faster and slower than some other languages again depending on the benchmark used.
I've seen benchmarks telling me that a 400MHz K6 is faster than a 600MHz PIII. Those benchmarks failed to mention in their results the conditions under which they were run: - software highly optimised to make use of special AMD instruction sets - motherboards and other hardware different between the systems, optimised for performance in the AMD machine only (using slower RAM, video, busspeeds on the Intel-equipped machine) - The Intel CPU was a Celeron (which the results failed to mention, listing the price of a full PIII even) - benchmark software optimised to give priority to AMD specific optimisations. - benchmark sponsored by AMD
Now, does this benchmark tell us anything except that there are unreliable benchmarks out there? Of course it does, it tells us that AMD were desperate to be seen as faster than Intel.
As far as I can tell, this benchmark isn't really relevant to answer the question 'Is Java slower..'. The reasons are:
1 - The only valid comparison here is to C - all the other languages are like Java in the way the code is run - so you can practically call them Java-like. It is interesting to compare Java to the pre-linked program in C. That's all (Interpreted Python is, of course, no match).
2 - Java was executed with the optimization just-in-time on. Since the benchmark tested predictable mathematical testing - the code that was executed was not interpreted after the first cycle.
Apart from that, the drop in trig-performance is a bit suspicious. There might be some problem there..
Writing benchmarks comparing Java with other languages has been a very popular occupation - google shows over 200 thousand hits for "java benchmark." Try it yourself! When looking at benchmarks it is important to note which version of Java is being tested as well as the operations in the benchmarks. The article I cited uses nothing but mathematical operations - hardly a broad spectrum of typical programming activities. Other benchmarks concentrate on OO related functions such as creation and GC of large number of objects.
Allegedly, the reason Java is slower than C/C++ in math is that Java requires strict IEEE floating point and the Intel math co-processors aren't compliant, so Java does its math using the CPU instead.
I completely reversed my opinion on Java's slowness when I tried out the Gentleware Poseidon UML tool. It's really cool to drag the mouse around in the little box down in the lower-left corner (zoom area) and see the big display smoothly scroll in response.
Loudly announcing something is true and finding out you're wrong makes you feel foolish.
Finding out you're wrong and refusing to admit it makes you LOOK foolish.
I downloaded the tests for c, c++ and java. Compiling of c and java-code went well. But the c++ - code had to be edited at many lines, because it was build for a MS compiler. For instance, it included 'stdafx.h'. While 'std' probably means 'standard', 'afx' might mean the opposite. I included 'stdio.h' instead. Constants of type 'long long' had to be suffixed with 'LL' to work. After fixing these problems (and ignoring some "ISO c++ does not support 'long long'"-messages) I was glad using my portable java.
Comparing the results, I mentioned that they differed from precision: Java-output showed 16, c++ 10 digits. Investigation showed: c++long-long is 64-bit, like java-long, so I guess it's only an output-formating question.
But the logarithm-function showed 7.00 for c/ c++ and 16.118 for java. Surprise! The test used 'log10 (i)' instead of 'log (i)' in c++. I changed it without effect to the performance, leading to 16.118 on cpp too.
Finally I tested java 1.5.0-beta-b32c, reducing the trigon.-time from 120 to 80 sec. But the tests weren't run in best lab circumstances - many threads running (but allmost waiting) during the 1.5 test. Mention: the IO-Test didn't use 'nio'.
In general, these tests only test - as mentioned before, number-crunching, not OO-Stuff. Few objects were created, no collections used, no gui, no database- or tcp/ip - connection created, no graphics displayed, moved, turned, zoomed, ..., Text layed out, ...
And instruction-performance is rarely important. Code maintainabilty, coding-performance, stability, security, reusage, portability, ... are important too. Time to get the java-code running on linux: 0 s. Time to get the c++ -code running on linux: 30 min.
(Well - if I had to this kind of job daily: 3 min.)