Talk:Java performance
 | Java Unassessed | |||||||||
| ||||||||||
 | Computing Unassessed | |||||||||
| ||||||||||
Comparing C++ and Java is not that easy
Please take care not to mingle Java and the JVM. Java is a programming language, the JVM a hosting architecture. C++ is a programming language, the x86 a hosting architecture. One might just as well decide to compile Java source code for the x86 or C++ code for the JVM. It is in general wrong to state "Java is slower than C++" instead of "A Java program on some JVM on some architecture is slower than a semantically equivalent C++ program run on the same machine." —Preceding unsigned comment added by 141.35.13.50 (talk) 12:41, 24 October 2008 (UTC)
Sun vs Microsoft Windows
This also belongs in the Criticism of Java article, but it should be noted that the lawsuit Sun brought against Microsoft hurt the consumer. Since the Microsoft VM no longer ships with Windows XP (or can be downloaded), any page that contains a Java applet will be frozen for up to 3min on slow systems while the JRE loads, This has not changed with , and is a significant detriment. There are some advantages to having a VM built into the OS's structure. LaVieEntiere 16:51, 30 April 2007 (UTC)
- The JRE only loads once, not each time an Applet is encountered. This is similar to having to download a new version of the Web browser, and not a significant obstacle. —Doug Bell 20:22, 7 August 2007 (UTC)
Need to differentiate Sun vs generic implementation
A general problem with several of the Java articles, but especially this one. SUN DOES NOT HAVE THE ONLY JAVA IMPLEMENTATION!!! Several of the "new" techniques discussed here (such as global register assignment) were done by other implementations in 1.2. Escape analysis and lock coarsening in 1.3 (if not bfore).
In another of the articles the concept of a stack-oriented IL is discussed as if it were a new idea, but it dates back to at least the P-code compilers for the original PC. IBM System i was using a stack-oriented IL (targeting a RISC engine with full global register allocation) several years before Java was introduced.
There needs to be some general technique introduced to distinguish between the quirks of Sun's implementation and the general architecture of the language. drh 03:07, 4 May 2007 (UTC)
Program Speed
Surely we need more references or benchmarks to support the claim "Java's speed is now comparable with C or C++ and in some cases Java is significantly faster". I am a professional programmer who works with both Java and C/C++ and in my experience, everything done in Java is MUCH slower. At the moment there is only a very questionable benchmark as a reference, which uses a 3D engine. This is a bad example, as the drivers/OpenGL api implementation would have more of an influence on the FPS than the actual language used. CptAnonymous 14:47, 8 September 2007 (UTC)
- I added the Jake example, but then I wrote: Java programs take more time to start, are slower and use more memory than their C or C++ equivalents. But I don't completely agree with you: OK Java is slower than C/C++, but not MUCH slower; and I think that the Jake example is relevant (but I agree that it is not a benchmark). 3D engines typically create a LOT of objects (outside the OpenGL API), and they need to update frames every few milliseconds. OK, the OpenGL driver performance is very important, but after that, the 3D engine used on top of it, and the game itself, are also important. Badly coded (or unfinished) video games typically lag (see Stalker, for example), regardless of the driver. Hervegirod 22:05, 8 September 2007 (UTC)
- I use C/C++ for real works (used to it + more portable), however if to think for desktop then my impression is that the java as language is also good looking, often easier to write than C++ and very quick language. Articles about "java perfomance" in wikipedia can no way raise the speed of the programs you write. What makes the real applications in java commonly slow is probably the widespread programming style. Feels like java developers do not often concentrate on solving the real problems of their users quickly and simplily and elegantly. Java developers seemingly concentrate (as first thing) on the modularity of software and the engineering process and feature-richness of their classes and modules (also important and welcome). However when one forgets for what he does it all ... it may result with perfect-looking foam factories (just a waste of power). java engines now optimize the bloat out runtime. Adjusting things with such a powerful engines drags down the starting and loading performance. So like usual ... the problems may lay between the chair and keyboard. Vambola Kotkas 212.47.207.152 (talk) 13:58, 4 February 2008 (UTC)
Escape analysis
Quote from article:
"Escape analysis techniques can not be used in C++ for example, because the compiler can not know where an Object will be used (also because of pointers)."
While Java may be able to do escape analysis more often than C++, it can be used sometimes in C++. For example the following code:
class Bar {
int inc(int i) { return i + 1 }
}
void foo() {
Bar b = new Bar();
cout << b.inc(7);
delete b;
}
with this code the compiler can know, that b will never be used outside of the function foo. I agree that pointers make escape analysis harder, but under certain conditions the compiler can verify that varibles do not escape a funciton. BTW, I have not programmed in C++ in a long time. Thus I may have made some syntactic errors. 213.237.48.86 18:48, 11 October 2007 (UTC)
Casts
The article says "that are possible in Java and similar languages are not possible in C or C++". To be fair it should be said that some optimizations made in C++ are not possible in Java. For example Java casts all objects extracted from collections. With C++ template-based collections, there is no need to cast extracted objects. I know Java has added generics, but the compiler still inserts casts. See http://www.jprl.com/Blog/archive/development/2007/Aug-31.html in the paragraph starting with "Runtime casts are inserted by the compiler" - I know, a better reference should be looked up. 213.237.48.86 19:21, 11 October 2007 (UTC)
- "the compiler != the compiler". Java is compiled twice. Generics and there cast are added by the javac complier. The JIT-Complier may produce different code. In the case of generics hints are added for the runtime, which can be used to optimize the code. However you can't guarantee type-saftie as you can cast any Collection to a generic collection and add different types of Objects. Java7 or Java8 will propably address it by introducing generic types into the jvm itself. --141.84.69.20 (talk) 17:37, 5 May 2008 (UTC)
Program Speed 2
It is really funny to compare java performance to C native code, and to conclude java is faster. The comparison of cost per functionality isn't discussed here, which is right, but virtually everyone knows that it is a big achivement if well writen java code is working only 2 - 3 times slower than well writen C code. My opinion is these conclusions to be erased. If most of you think in similar way, let erase them. Dobrichev 21:38, 23 October 2007 (UTC)
- I have seen a proof that ... current java actually often performs comparably runtime. Still slower, true, but not by the factor of 3 anymore. Real apps we see around however are really slow. It seems is not as the fault of the engine but the engineers. Maybe java fans do not know what is "profiler"? Vambola Kotkas 212.47.207.152 (talk) 15:54, 4 February 2008 (UTC)
Öhm?
I'm not an expert on this, but I just wonder how much of Java VM and all that stuff is written in C/C++? --212.149.216.233 (talk) 13:25, 20 February 2008 (UTC)
AFAIK, the whole Sun's JVM / JIT-compiler is in C++. The bytecode compiler (javac) is in Java itself. Hervegirod (talk) 23:09, 1 April 2008 (UTC)
Contradictory speed discussion
Clearly there is some disagreement about speed. Nothing wrong with that. But the article makes two statements that directly contradict each other: 1) "Hence, when Just-in-time compiled, its performance is lower than the performance of compiled languages as C," and 2) "Java's speed is now comparable with C or C++." Perhaps there is not a sufficient consensus that can be backed up by verifiable references in which case the article should not make claims either way (and should just point out that performance is a controversial issue, citing appropriate references to the controversy). Or perhaps there is. Either way the article should not say both that Java performance is lower and that the performance is comparable. —Preceding unsigned comment added by 71.84.19.38 (talk) 22:15, 1 April 2008 (UTC)
Collections microbenchmarks
There was a comment about these microbenchmarks saying: However the test is probably biased against C++ since it creates "dynamic objects" even if C++ can create stack objects while Java can't. Heap allocation is slow in C++ since its a general mechanism that should be used only if really needed.. I rewrote it a little to make it more neutral (the probably was not sourced based, so I changed by may be), and I put a fact tag, because when looking at the article in question, I saw nowhere if the author used heap or stack for initial memory allocation of the Objects. Plus Objects defined by STL are allocated on the stack, even if the memory itself can be allocated on the heap. Hervegirod (talk) 19:11, 4 August 2008 (UTC)
- I took that out, because generally we shouldn't argue against citations in Wikipedia's voice. If someone else criticized the benchmarks for that reason, we can say so and attribute the criticism to them. In general though this section is fairly bad; it seems to consist mostly of poor benchmarks run by random people on the internet (or journalists) rather than peer-reviewed papers. --Delirium (talk) 19:37, 10 March 2009 (UTC)
this page is clearly biased
this wikipage is clearly biased, doesn't give enough references and is cherrypicking the ones it does, for example in the quake2 example it gives the impression that the java implementation is faster but if you look at the page you will see its not that simple, actually the fastest performance overall was for c ( http://www.bytonic.de/html/benchmarks.html)
sorry i dont have more time to go over this page but its so biased its ridicolous, and i even like java —Preceding unsigned comment added by 85.83.19.244 (talk) 21:36, 4 April 2009 (UTC)
- Hey if you don't like these references, add some, but I don't think that this article is biased overall. Plus you also seem to do cherry picking. The part about Quake2 is The Java 5.0 version performs better in some hardware configurations than its C counterpart. And some other parts you did not pick: Performance of trigonometric functions can be bad compared to C, JVMs still have scalability issues for performing intensive communication on a Grid Network, Java memory usage is heavier than for C or C++, Java startup time is often much slower than for C or C++. Hervegirod (talk) 22:56, 4 April 2009 (UTC)
A controversial paragraph
This paragraph appears to be biased:
The author needs to cite his/her references, and how these conclusions were made (When the test was done, by who, the conditions, etc.) —Preceding unsigned comment added by Valenajarro (talk • contribs) 22:13, 9 June 2009 (UTC)
- Seems POV to me. Hervegirod (talk) 22:18, 9 June 2009 (UTC)
Additions in the introduction
Concerning the addition in the intro:
- Comparing the performance of Java programs with those of the ones written in C, C++, Object Pascal or other (usually) natively compiled languages, is a tricky and a controversial task. Java, Like C++, is a programming language, but its target platform is (usually) the Java Platform, nowadays implemented in the JVM. The programs written in C, C++ or Object Pascal are compiled specifically for a hardware-OS combination that conforms a platform.
I think there's a difference between evaluating Java programs and C / C++ programs performance, but not as it is stated in this sentence. Performance of C / C++ programs also very much depend on the compiler and the OS architecture. What is different is the fact that Java programs are JITted, and the performance of a program very much depends on it's history. Hervegirod (talk) 22:57, 10 June 2009 (UTC)
- Introduction changed to clearly reflect this situation (it was implied) . Valenajarro (talk) 22:18, 9 June 2009 (UTC)
Article non-neutrality
As other posters have pointed out, many parts of the article use biased wording and there is also apparent cherry-picking of benchmarks and benchmark results. I am marking this article POV until the problems are fixed (unfortunately it seems to require a lot of rewriting). Tronic2 (talk) 14:30, 19 March 2010 (UTC)
- A lot of my time critical code executes in Java (video codecs specifically), but I compile from C++ when I develop (clever macros convert the same source code to either Java or C++). This makes it easy to compare the code speed - as it is the same code. My experience at least is consistent with the article - comparable execution speed in Java and C++. It's worth mentioning that there are a few things I avoid to encourage this - such as no garbage generation / collection. Stephen B Streater (talk) 21:25, 19 March 2010 (UTC)
- I think some people see what they want in this article. I think I have to write again my previous answer to somebody else, a long time ago: "(...)I don't think that this article is biased overall. Plus you also seem to do cherry picking. The part about Quake2 is The Java 5.0 version performs better in some hardware configurations than its C counterpart. And some other parts you did not pick: Performance of trigonometric functions can be bad compared to C, JVMs still have scalability issues for performing intensive communication on a Grid Network, Java memory usage is heavier than for C or C++, Java startup time is often much slower than for C or C++". About garbage collection, reclaiming memory is not only Java related (every real-life C++ program must claim and reclaim memory all the time, with the associated risks of course), and studies (not Java related), show that: good GC can have the same performance as good manual allocation / deallocation (even faster in some cases), but uses much more memory(see here). The fact that Java programs uses more memory than their C counterparts is mentioned clearly here. About my personal experience, it's very easy in Java to create programs which create and garbage a lot of objects (much more than in C++, where you have to be very careful to avoid memory leaks). But creating / deleting objects comes at a cost where you do this VERY often. Hervegirod (talk) 22:20, 19 March 2010 (UTC)