Talk:Java performance
 | Computing Unassessed | |||||||||
| ||||||||||
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)
Collectoins 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)