Talk:Java performance

message: In the "Program Speed" section it says that "The C implementations are on some examples 4-5 times slower". Nothing can be "x times slower" than something else. That doesn't make sense.  —Preceding unsigned comment added by 129.53.219.20 (talk) 14:50, 12 May 2010 (UTC)
thread_title:  "x times slower" 

message: 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)
thread_title:  Comparing C++ and Java is not that easy 

message: 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)
replies: text: 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)
thread_title: Sun vs Microsoft Windows

message: 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)
thread_title:  Need to differentiate Sun vs generic implementation 

message: 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. Acadgild 14:47, 8 September 2007 (UTC)
replies: text: 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)
replies: text:  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)

text: Stating "Java is comparable or faster than C++ in benchmarks" is dubious at best. Even the reference given lists Java only slightly slower in the best case and three or four times slower in the worst case. The only benchmark which shows a significant speed ratio in favour of Java is a ten year old benchmark run on a Pentium II 400, which was very selective and biased from the beginning. 87.167.157.146 (talk) 09:04, 23 April 2010 (UTC)

text: It is worse than dubious at best: Im a programmer I eat code for breaky, Ive written blindly fast code for many platforms and architectures, I know just what is wrong with c++ and c
and how they neccessarily confuse the heck out of the compilers optimiser. aka Im qualified to read or even write whatever authoritative' sources that you are going to cite. The cited references, disprove what the page claimed them to support. One satement was that java was not 'significantly' slower, I went to the reference and examined the data it was best summarised as "java is twice as slow", your page summarised it in sunesk java speak.
Ive used real world java apps and c++ ones the java ones are in gamer speak laggy. That a useless distinction, probably as are the benchmarks. Everytime I have tried to speed up numerically intense code written in c++, by someone other than me, it generally went between 2x and 10 times faster... The next refrence I checked was that low level or numerical code could be comparable. On that link I actually found two benchmarks where java was faster. Generally it was slower, by an amount hat is not insignifcant to me. However I also have some suspicions about the benchmarks. Java was measured I beleieve on the task of say puttign all the apples in the box, whereas c++ was measured on putting them in and taking them out. Huh? Well I suspect the java program had allocated all the memory(there was oodles of allcoations) and had not yet garbage collected it. This means that in the real world when you do the next task, the garbage collector will still be running and slow it down. To be a real test, the test needed to be long enough to force that distinction out of the equation.
Indeed most tests, dont simulate the real behaviour of java in real apps as they run trivial apps for trivial time frames. Real java behaviour for typical programs allocates and garbage collects lots of fluff. This fragments the heap, fragmenting the heap has always slowed down c++ code that I have written. The list of issues pitfalls with any formal testing game unless perused by 'real' experts, is monumental. The most accurate scientific non subjective estimate I have for the speed difference of Java and C++, is I feel mature java apps Ive used were laggy when compared with native ones. Any attempt Ive seen tto examine actual data and refeneces on the wikipedia page, is more subjective, in that it doesnt even measure what it claims to, speed on sane benchmarks, nor does it report the actual numerical results accurately. Frankly its the wrongest page Ive seen on wikipedia. Frankly it smells of marktroid drone speak. Are you sure your editors do not have (at best)divided allegences, yeah thats rude, but sorry I smell a rat. My advice if your a rat reading this, hide the sun speak better. BTW Im going now got to get back to coding my current project in my lanuage of choice for the project Java. Write once run anywhere, trumped my other requirements/considerations.     
Note i described something above as a 'formal testing game' as agame because benchmarking (producing fair tests) and cheating them is game played by languages compiler vendors and the benchmarkers. The benchmarkers are the least well funded. 
Oh and BTW if a benchmark is heavily efefcted by escape analysis, then IMO its crap as ameasure of speed as it impacts the readers of this page. Amyone who actually evaluates 
saya a fibonacci using dumb recursion down the buinary tree, deserves runnign logN times slower. if it was trivially optimisiable like that then agood programmer never wrotew it in place that mattered to real apps importance. Yes its handy to have escape analysis, yes it will speed up real apps small amounts, but showing that alanguage that has it suddenyl does much better on some benchmark simply proves the bencmark is crap as measuring how real world things could be expected to work.
I take issue with the statement:  "its performance is generally:...lower than the performance of compiled languages as C or C++".  The reference provided to support this claim, i.e. http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php indicates that Java is 2 times slower.  Can we change this statement? Tcotco (talk) 06:37, 20 July 2010 (UTC)

text: "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)
thread_title: Program Speed 

message: 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)
thread_title:  Escape analysis 

message: 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)
replies: text: "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)
thread_title:  Casts 

message: 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)
thread_title:  Öhm? 

message: 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)
thread_title:  Contradictory speed discussion 

message: 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)
replies: text: 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)
thread_title:  Collections microbenchmarks 

message: 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)
replies: text: 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)
thread_title:  this page is clearly biased 

message: This paragraph appears to be biased:
Despite all these improvements complaints are being voiced about user programs written in Java, which continue to offer poor user interactivity after years of development and a decade of JVM improvements. Supporters point out the progress made so far and detractors compare the user experience with that of a program written in C++. An example is Eclipse, which pauses for several seconds when doing trivial operations and in general has delays that break programmer flow. There is a communication problem because supporters of managed languages often use them so much that they subconsciously accept the load delays and the pausing of the program. It's worth noting that it remains impossible to write a program like Maya or Cubase in a managed language, chiefly for usability reasons.
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)
replies: text: Seems POV to me. Hervegirod (talk) 22:18, 9 June 2009 (UTC)
thread_title:  A controversial paragraph 

message: 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)
replies: text: Introduction changed to clearly reflect this situation (it was implied) . Valenajarro (talk) 22:18, 9 June 2009 (UTC)
thread_title:  Additions in the introduction 

message: I won't add to the bias debate although this would probably provide one more evidence: "Java garbage collectors can do more than collect garbage, they may also defragment memory by moving objects that are not garbage near to each other in memory. This is, for example, a common feature of the generational garbage collectors mentioned above. This may result in a smaller working set of memory pages, and therefore quicker memory access.".
My problem is with "and therefore quicker memory access". Come on! Unless I am completely mistaken, memory accesses with respect to RAM is random and direct and linear, meaning that whatever the position where you read data from (or write data to), the operation is performed in a constant time, all other factors (for instance, the size of the data) remaining the same. The position/address is totally orthogonal to the operation. So claiming that a smaller working set means quicker memory access is clearly putting anything on the advantages side just for the sake of putting something (by the way, the defragmentation feature of garbage collectors is mind-blowing in and of itself, no need to add anything). As far as I know, whatever the language (C, C++, Java), all blocks of memory allocated are contiguous; so each object's fields are always in one single block even if individual objects' blocks may be non-contiguous. How on earth could a smaller working set provide faster memory access? We are not talking about disk sectors here, or page ins/page outs or virtual memory as handled by the OS. We are talking about memory from the point of view of the garbage collector. What is claimed would sometimes be true if virtual memory or paging were evoked in one way or another, which was not the case. If there's no paging in the picture, a smaller working set does not equate, imply, guarantee, or whatever you name it, quicker memory access. That's just plain wrong. A smaller working set means more readily-allocatable memory for other processes and the system, but that's not what is dealt with here.  —Preceding unsigned comment added by Amenel (talk • contribs) 16:29, 15 May 2010 (UTC)
replies: text: Well, smaller working set sometimes may be beneficial, sometimes not. It depends. What is not true, that smaller working set is obtained. Programs using GC require much more memory than without GC, so even with defragmenting GC programs still consume more memory than programs not using GC.Alliumnsk (talk) 03:44, 27 May 2010 (UTC)
replies: text:  This is a benefit.  I am not a pro-Java advocate.  Think about caching.  Suppose a page size is 4k.  Then a set of 256 bytes could take 256*4k=1M of actual memory.  If the system must write some memory to disk to satisfy this criteria, then de-fragmenting the memory is a big pay off.  Most C allocations use sbrk underneath and are binning. So the extreme example would never seldom happen, but it illustrates the problems of fragmentation.  With generational GC, seldom used objects can be pushed to disk (virtual RAM) faster.  Err, sorry that is un-true.  I had thought about mentioning that to Doug Lea.  You could coallse seldom used active memory so that the pages can be swapped.  ... Given my real life experiences, with Java developers piling package after package on to a problem, I haven't seen this in real life.  I would like to be surprised.  Java has some very elegant features.  However, the morass of un-intentional memory references usually ends up depleting memory sooner.  I believe that 'C' and 'C++' generally require more analysis up front, which might lead the average program to pay more attention to these issues. Bpringlemeir (talk) 21:06, 9 June 2010 (UTC)

text: Memory access is far from random nowadays. Memory access is what governs the execution speed. Cache hierarchy improves otherwise slow main memory, odds to get better caching properties is what defragmenting does. Also generation GCs do not need to walk to heap to find an empty room for the next allocation. Generally speaking Java is faster than C++ on allocation, depending on malloc lib of course. Most of JVMs use thread local area where allocation is just a pointer bump (similar to allocation on the stack) and it's lock free, i.e. each thread can allocate without contention provided the object is not too big and fits in there. Java does not necessarily consume more memory per se but it's the fluffy programming style that contributes along with some memory inefficient data structures (like java.util.HashMap). Bestsss (talk)  —Preceding undated comment added 08:07, 1 October 2011 (UTC)
replies: text: Unlike Java, C/C++ has static allocation (which is free) and automatic allocation (which is O(1)). So while Java's new is faster, memory probably was allocated at compile or link-time in C/C++ program. There is no way to do that in Java...Alliumnsk (talk) 08:52, 23 October 2011 (UTC)
thread_title:  Obvious non-sense 

message: I object to this edit, as it removes quite important point that Java code, even if JIT compiled, is considerably slower than native code, generated by modern optimizing compiler. I agree that the reference is written in anti-Java style and that it should be replaced by more appropriate one, however the style has nothing to do with the validity of material presented there. As of now, I revert the objected revision because the reasons specified in the edit summary are not valid: 1) stack allocation is considerably faster than heap allocation and allocates memory area which is almost certainly cached. 2) lock-elision is important only for Java applications as Java makes everything thread-save by default, what is not needed for most code. 1exec1 (talk) 16:36, 23 August 2010 (UTC)
replies: text: The Jelovic source is absolutely not reliable. The document itself has no date (judging by the version of FrontPage used, and some of his sources, the document may date from 1998 or 1999, that would be Java 1.2), Delan Jelovic is unknown on the radar, and he did not substantiate any of his claims except by very general sources that are not relevant to the performance subject. Therefore I'm obliged to revert your own edits. Remember that one of the principles of Wikipedia is No original research. I have nothing at all with such claims, but they must me substantiated by a reliable source, which was not. BTW, I was not the one who reverted the source the first time. Hervegirod (talk) 07:53, 24 August 2010 (UTC)
replies: text:  Agreed. After quick search I found two recent sources, which should not be considered POV: this,  this.1exec1 (talk) 12:50, 24 August 2010 (UTC)
thread_title: Revetred edits 23 August

message: There's 5 sources.
*First says that Java solutions are typically slower, TLs same, 
*Second says that Java solutions are often slower, TLs same, some problems might be not solvable in Java (as TLs are set after non-java reference solution, which is faster)
*Third says they use 3x TL + 150ms/file
*Fourth says they use 2x TL
*Fifth says they use TL + 1sec
where's problem?
Alliumnsk (talk) 22:16, 21 September 2010 (UTC)
replies: text: I don't think these references are really valid. Unfortunately, some people here look everywhere to find sources saying that Java is *much* slower than other languages, regardless of their consistency and validity. Hervegirod (talk) 21:49, 27 November 2010 (UTC)
replies: text:  What do you consider as not valid? Do you think all of them really use identical time limits for Java and C? Maybe I formulated it unaccurately. The sources do not tell *how much* Java is slower, but only about if they give more time for Java solutions or not.Alliumnsk (talk) 01:44, 5 December 2010 (UTC)
replies: text:  The paragraph begins not very well, by "Programming contests provide by far the most objective known performance comparison", but this sentence is only an editor point of view on the topic. There is nothing objective here. Apart from the fact that this sentence is not in sources, one could also say that they do this to avoid to be criticized by contestant who might say "you did not give me enough time to do to job in Java, etc.., but Java is slower, therefore I contest the results. I won't put this in the paragraph, because it is also my POV on the subject, it's just to show you that there is nothing "Objective" on Java performance to get in programming contests rules. Hervegirod (talk) 13:34, 5 December 2010 (UTC)
replies: text:  I agree with you on first sentence. Otherwise I don't get your point. Judges are often blamed by erronenous or subjective reasons; they do what they consider fair and not because of criticisms. Contests are objective. Read about how solutions are checked. Alliumnsk (talk) 14:27, 5 December 2010 (UTC)

text:  Quoting the TJU contyest FAQ about java: Any of illegal or dangerous operations are forbidden, such as file-open, socket, thread. That does not seem very objective to me. So threading is dangerous, but pointers are not? Plus TJU increase limit to double of C, but the benchmark game (not biased toward Java, and much much more consistent as for testing conditions) shows that Java is about as fast as C in most of cases. Just saying "java programs can be much slower" without any evidence is not valid. Which does not mean that the Programming contest paragraph is not valid, but getting a "is Java fast?" conclusion with these is not IMO. Hervegirod (talk) 15:12, 5 December 2010 (UTC)

text:  You seem to misunderstand what the contests are. Programs are not allowed to store intermediate data between runs, or communicate with something else. Otherwise it could send data to contestants, or even read judge's with correct answers. Dangers of pointers are handled in hardware and operating system already (a contestant's program can only ruin itself), so judges don't need to worry about that, and C cannot operate without pointers. Shootout is not more consistent - because it strongly depends on availability and willingless to complete in shootout. Haskell community, for example, does considerable efforts to complete, and FORTRAN does not. That is, amount of man-hours is not shown in shootout, when in contests each contestant has a strict limit. And shootout features only a about a dozen of tasks, when various contests have produced hundreds and thousands of problems, run by near-professionals. Shootout link you posted does not show what you claim - for most tasks. That is about as much difference with Celeron D and Core 2 Quad processors. Java is fast, when compared with dynamically typed languages, or outdated C implementations, though.Alliumnsk (talk) 13:00, 6 December 2010 (UTC)
thread_title:  Programming contests 

message: presenting the winning of terabyte sortbenchmark is misleading on indicating something on the Java performance. The rules of the graysort benchmark stating nothing about a defined hardware base for the competitors. So the setup with the most ressources had won, not the best implementation ('most efficient'). Hadoopsort run on approx. 4000 working nodes by far more then the next one. This can be also be seen by the non-ranking in the efficency benchmarks Penny- and JouleSort.  For comparision google was able to beat hadoop by raw speed as efficiency in 2008 (not in benchmark): http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html . 141.52.232.84 (talk) 14:26, 26 November 2010 (UTC)
replies: text: Yes, this was an issue I noticed some time ago, but didn't fix because someone kept reverting me. Fixed now. 1exec1 (talk) 21:19, 27 November 2010 (UTC)
replies: text:  This is your personal interpretation, and it's not backed by valid sources, so I'm putting it back. let's stay on  facts guys, not on our personal conceptions: Hadoop won the benchmark several times, hadoop is written at 99% in Java. All of what your are writing here is YOUR personal interpretation of the reason why hadoop won the benchmark. Rather than putting you own OR interpretation here, I would prefer seeing valid sources commenting the fact that hadoop won, and that (maybe) it was only due to the fact that it won only because of hardware.  Hervegirod (talk) 21:32, 27 November 2010 (UTC)
replies: text:  agree, problem is the interpretation of a benchmark with multiple free parameters (this is an benchmark not about languages or implementation but of complete systems). nowhere in the references it is stated that the mentioned sort system won BECAUSE of the underlying framework or even the programming language. Nor can such conclusion be taken because of undefined constraints on hardware, connection etc by the Gray sort definitions. so, putting this on a wiki-page about java performance at all is a highly speculative interpretation. (here someone discussion the problem of undefined hardware-setup http://databeta.wordpress.com/2009/05/14/bigdata-node-density/) 95.114.244.145 (talk) 18:04, 28 November 2010 (UTC)
replies: text:  many high-profile distributed database management systems use Java  rather than C++: for example, Cassandra, Gemstone, GigaSpaces, DataSynapse, etc... and it's for a reason. And the reference is not speculation, it's facts. Note that it does not state that "Java is faster in HPC other other languages", but that Hadoop, a Java MR implementation,, has won HPC benchmarks. I don't see where is the speculation here. You are more than welcome to point to sources explaining that the major reason explaining that the reason why Hadoop won the benchmark was not java, but the hardware. However, I was not able to find any (which does not mean that there are no valid ones). The sentence above quote sources explaining in what ways java has issues for HPC.  And about the google implementation that was quoted in an above comment, it is not public, so we don't have any detail on how it work (except that it use MR). Hervegirod (talk) 19:07, 28 November 2010 (UTC)

text:  sorry, wikipedia has not a policy of "true until proven wrong". So it's way around. references are required which proof that this hadoop sort benchmark setup allows a undebatable conclusion that the performance is definded by the underlying java (and not the hardware: the reference above (http://databeta.wordpress.com/2009/05/14/bigdata-node-density/) show doubt about this point, with even the conclusion that the hadoop setup is overly pessimistic and therefore approx. 40x times more hardware hungry (slower) then alternative setups). If such references are not available this benchmark is not relevant and note-worthy for this article. Or at least some additional information should be added which are helping the reader in understanding the undefinedness in the gray benchmark about the hardware setup. 95.114.244.145 (talk) 22:33, 28 November 2010 (UTC)
replies: text:  This is the second time yo put the DataBeta blog in the discussion. DataBeta is not a valid source. It's a blog from an "unknown" individual. Blogs are not considered valid sources here, except when they are from prominent figures in their fields, which does not seem to be the case here. His post is challenged by a lot of comments. The other source (the google's one) is even more "gray", because how google pbtianed these results is not public. They only posted a result, without explaining how they obtained it. So I'm sorry, but I still consider the paragraph valid. Hervegirod (talk) 00:30, 29 November 2010 (UTC)
replies: text:  doesn't matter if the google implemenetation or this blog are unreliable, undefined etc. because they wasn't given for inclusion, but for discussing the invalidity of conclusion presented in the included paragraph. The included paragraph is on a unencyclopedic level by indicating an invalid conclusion on the java performance from an benchmark which is not well defined enough for allowing such an conclusion. still, bring an reference which clearly state/proof that this benchmark result has something to do with the underlying java, not one of the given/included (redundant) sources is saying that. 95.114.236.201 (talk) 10:55, 29 November 2010 (UTC)

text:  several people were already noticing the problem of this paragraph, see edits 380704995, 312698980 ... at least this already existing sentence should be re-added ..., although the hardware setup in the benchmark competition was not fixed and the Hadoop cluster had more than 9 times as many processing cores as the next closest contestant. Also, hadoop seems not 100% java http://hadoop.apache.org/common/docs/current/native_libraries.html 141.52.232.84 (talk) 17:32, 29 November 2010 (UTC)

text: hervegirod, the additional NPOVing text is some form of compromise...if you keep removing and standing on this invalid point of view the strict alternative would be to remove this paragraph at all, because no resources were presented which concluded java as reason 95.114.32.28 (talk) 23:57, 30 November 2010 (UTC)
replies: text:  I did not go back to this article for a long time, and I happen to discover that the google source used to explain that hadoop had 9 times more cores than the second contestant did not say that at all. It even did not say the number of cores that the google implementation of MapReduce used (contrary to hadoop, which explains the hardware they used in detail). it is very easy to debunk an implementation which is opened about how it works, and compare it to other which are not. The google blog says: We are excited to announce we were able to sort 1TB (stored on the Google File System as 10 billion 100-byte records in uncompressed text files) on 1,000 computers in 68 seconds. By comparison, the previous 1TB sorting record is 209 seconds on 910 computers. I am not against writing that MapReduce had 9 times more cores than the second contestant, but please use a valid source for that, and don't infer C from A and B, this is not valid here. Hervegirod (talk) 13:56, 1 January 2011 (UTC)
replies: text: Hello Hervergirod, looks like this discussion was already before... but checking the site of the Sort benchmark for the mentioned "Gray results" it seems there is not definition of the hardware setup, it's a benchmark of complete systems not software. So referencing this benchmark might be invalid for this software page overall. what do you think? Shaddim (talk) 11:21, 19 January 2011 (UTC)

text:  I've removed any speculation about the links between the hardware setup and the good performance of Java implementation in the competition. However, I think that mentioning mere fact about the unfixed hardware setup is necessary, the readers can then draw the conclusion themselves. 1exec1 (talk) 19:07, 19 January 2011 (UTC)
replies: text:  I've not checked this discussion for a long time, hence the delay to answer ;) However, I think that this current wording is right. Hervegirod (talk) 15:16, 10 July 2011 (UTC)
thread_title:  Sort performance

message: I'm going to remove this bullet point from the Program speed section for now:
Collections,[50][51] Heap allocation, as well as method calls[52] are much better in Java than in C++.
because, looking at the cited article, I think the word "collections" there is a misleading characterisation, but I'm not sure the correct way to reword it.  The most obvious thing is that the cited graphs aren't comparing collections performance in general, it's specifically looking at HashMaps.  But I don't think changing it from "Collections" to "HashMaps" would be enough.
The code the author provides shows that that test consists of two loops which: allocate memory off the heap, convert an integer into a string, do a hash-table lookup or insert, and then deallocate the memory.  There's no way the hash-table lookups make up more than a fraction of the time for that in either language.  Also, in the C++ benchmark, the integer conversion is done using generic IO routines, while the Java benchmark uses an integer-to-string function.  So the actual performance comparison is with heap allocation and C++ I/O routines vs. Java string conversions.  That's a pretty complex and highly-specific thing to put in that bullet point in place of "Collections."
I figured I'd be bold in removing the misleading bit, but let the more involved editors make a judgement call on how to fix it.  Personally, I think "Collections" should just be removed from the bullet point, because going from "heap allocation, I/O routines, string conversions, and hash maps" to "collections" seems like a bit of original research to me.  (The [52] graph also looks far too close to justify saying "much better," especially since the C++ compilers fall between the server JVM and client JVM.)  
More broadly, though, regarding using that article as a source here, it may be worth reconsidering whether the cited article actually says what's being attributed to it.  The author deliberately chooses not to analyse or explain the results.  If we use those graphs to assert that one language is faster than another in some case, we're choosing to interpret the results ourselves. BMKane (talk) 20:33, 25 November 2011 (UTC)
replies: text: I add this article as a source myself, and I'm against removing parts of it just because editors here (editors include me as well) feel that the article is to broad or insufficiently explain the context of some performance comparison. The article does not write that java is faster than C++, it just present benchmarks about specific low level operations, and find some which are much faster in C++, some which are faster in Java. It's true that the benchmark about Collections was about various kinds of maps, however I don't understand why you want to remove the reference as well, rather than just change it to Maps. And removing a valid source (I don't think anyone would imply that Dr Dobbs source should be deemed not valid by default) seems really odd to me. Why not just stick to rewording what you thought should be reworded, rather than removing everything? The article talked about single Hashmapsand multiple Hashmaps, so even if I agree that naming it as Collection is too broad, maps is really the term that should be used here. Hervegirod (talk) 16:47, 26 November 2011 (UTC)
thread_title:  Program speed Collections bullet point 

message: I removed the source for the java memory overhead here: This leads to a significant memory overhead for small applications when compared to its best known competitors Mono or .Net, and i added a fact tag. While it's generally accepted that Java has a significant memory overhead, the comparison with .NET and Mono in the source is not valid:
* the author is not known at all, and the article was not chosen or edited at all, it has the same validity than a blog by any individual
* furthermore, the programs he used to do the comparison for each language do not do the same thing at all, they are not equivalent. For example, for WPF / MFC / Forms, the author chose not to show any UI at all, he only started the UI framework. While for Java he also created a frame with various elements in it. Hervegirod (talk) 23:28, 5 January 2012 (UTC)
thread_title: Memory overhead source

message: I removed this article from the compiler optimizations category as it seems to me that that category is for, well, optimizations that a compiler can do, not things that use compiler optimizations. —Icktoofay (talk) 03:38, 15 January 2013 (UTC)
thread_title:  Compiler optimizations category 

message: I've removed an old neutrality tag from this page that appears to have no active discussion per the instructions at Template:POV:
::This template is not meant to be a permanent resident on any article. Remove this template whenever:
::#There is consensus on the talkpage or the NPOV Noticeboard that the issue has been resolved
::#It is not clear what the neutrality issue is, and no satisfactory explanation has been given
::#In the absence of any discussion, or if the discussion has become dormant.
Since there's no evidence of ongoing discussion, I'm removing the tag for now. If discussion is continuing and I've failed to see it, however, please feel free to restore the template and continue to address the issues. Thanks to everybody working on this one! -- Khazar2 (talk) 18:47, 29 June 2013 (UTC)
thread_title:  removing POV tag with no active discussion per [[Template:POV]] 

message: It's downright silly to say that a JIT Compiled Java version of Quake is faster than a 16+ year old 32-bit, C version of Quake. (Remember Moore's Law?) If the source code is available to RECOMPILE a Java program, then it's ALSO available to recompile a C program with modern optimizations. I don't have a "side" in this debate. I only ask that the comparisons made be actual, factual, fair ones. 
Cache size and speed has change. Optimizations have changed (loop unrolling can overload cache size). Numbers of CPU's/cores has changed. If we're going to compare C and Java, they should both be using--at the very least--compilers from the same era. 
Novous (talk) 06:27, 7 December 2013 (UTC)
thread_title:  Program Speed, the quake comparison 

message: Cyberbot II has detected that page contains external links that have either been globally or locally blacklisted.
Links tend to be blacklisted because they have a history of being spammed, or are highly innappropriate for Wikipedia.
This, however, doesn't necessarily mean it's spam, or not a good link.
If the link is a good link, you may wish to request whitelisting by going to the request page for whitelisting.
If you feel the link being caught by the blacklist is a false positive, or no longer needed on the blacklist, you may request the regex be removed or altered at the blacklist request page.
If the link is blacklisted globally and you feel the above applies you may request to whitelist it using the before mentioned request page, or request it's removal, or alteration, at the request page on meta.
When requesting whitelisting, be sure to supply the link to be whitelisted and wrap the link in nowiki tags.
The whitelisting process can take its time so once a request has been filled out, you may set the invisible parameter on the tag to true.
Please be aware that the bot will replace removed tags, and will remove misplaced tags regularly.
Below is a list of links that were found on the main page:
*http://java.dzone.com/articles/escape-analysis-java-6-update
*:Triggered by \bdzone\.com\b on the global blacklist
If you would like me to provide more information on the talk page, contact User:Cyberpower678 and ask him to program me with more info.
From your friendly hard working bot.—cyberbot II NotifyOnline 18:33, 8 December 2013 (UTC)
thread_title:  Blacklisted Links Found on the Main Page 

message: The opening summary states that Java performance is "not much different" from C++ citing a blog article which claims that "it's a tie."  The body of the article states that Java micro-benchmark "performance is generally slower than or similar to compiled languages such as C or C++," referencing the Computer Language Benchmarks Game.  The latter is a weaker and, in my opinion after reviewing both sources, probably the more accurate claim.  I recommend making the claims in both sections consistent with one another.  Thoughts?  21:31, 4 Mar 2013 (UTC)
thread_title:  Self-contradictory Information in Summary and Body 

message: Reference number 4 is a dead link that leads to a parked website.  Can someone please fix this? 134.129.205.205 (talk) 22:43, 11 December 2014 (UTC)
thread_title:  Reference 4 

message: "Objectively comparing the performance of a Java program and an equivalent one written in another language such as C++ needs a carefully and thoughtfully constructed benchmark which compares programs expressing algorithms written in as identical a manner as technically possible."
Try this:  "Objectively comparing the performance of a Java program and an equivalent one written in another language such as C++ needs a carefully and thoughtfully constructed benchmark which compares programs completing identical tasks."  How one would design and code something in Java should have no impact on how you design and code it in C++ and vice versa.  Imagine applying that rule in, say, a JavaScript vs. 6502 assembler comparison.  - Richfife (talk) 20:43, 29 April 2016 (UTC)
thread_title:  First sentence of "Comparison to other languages" 

message: This is basically saying Java has an advantage because it is compiled specifically for the hardware that it runs on.  I see variations on the claim a lot, but to be honest, it's put up or shut up time.  Is there any real world evidence that statically compiled code running on a modern processor can be significantly outperformed by code compiled per machine?  I've not seen any. - Richfife (talk) 21:58, 29 April 2016 (UTC)
thread_title:  "Other compilers almost always target a specific hardware and software platform, producing machine code that will stay virtually unchanged during execution. " 

message: While performance of running programs is covered, something everyone knows but never discussed is how slow java server apps (jvms) are to start (and stop). I don't think it's a small matter, either, as a simple restart is no longer trivial enough to not have to build tooling around, since restarts can take over a minute (and cause outages). I feel it should be mentioned.  — Preceding unsigned comment added by Kelt65 (talk • contribs) 00:14, 20 October 2016 (UTC)
thread_title:  "Speed" ? 

message: Hello fellow Wikipedians,
I have just modified 6 external links on Java performance. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20100331155325/http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf to http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf
*Added  tag to https://jdk.dev.java.net/verifier.html
*Added archive https://web.archive.org/web/20070105224757/http://weblogs.java.net/blog/campbell/archive/2005/07/strcrazier_perf.html to http://weblogs.java.net/blog/campbell/archive/2005/07/strcrazier_perf.html
*Added archive https://web.archive.org/web/20060516011057/http://forums.java.net/jive/thread.jspa?messageID=94530 to http://forums.java.net/jive/thread.jspa?messageID=94530
*Added archive https://web.archive.org/web/20080221131118/http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=195 to http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=195
*Added archive https://web.archive.org/web/20050214080519/http://janet-project.sourceforge.net/papers/jnibench.pdf to http://janet-project.sourceforge.net/papers/jnibench.pdf
*Added  tag to https://jna.dev.java.net/
*Added archive https://web.archive.org/web/20091015215436/http://developer.yahoo.net/blogs/hadoop/2008/07/apache_hadoop_wins_terabyte_sort_benchmark.html to http://developer.yahoo.net/blogs/hadoop/2008/07/apache_hadoop_wins_terabyte_sort_benchmark.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 23:21, 22 November 2017 (UTC)
thread_title:  External links modified 

message: For example, "if the size of an object is not 8, it is rounded up to 8" is not just something Java does -- it's C++ and other such languages too. Citing this as a Java thing is not exactly prudent. As well, the lack of address arithmetic (as said in article) is simply a consequence of a GC-based language, and most of the structures listed aren't something I see as necessitated. 
The memory use of the JVM and such are per-implementation, and therefore not something that can be broadly said to apply to Java.216.186.142.254 (talk) 19:34, 16 August 2019 (UTC)
thread_title:  Most of the memory use section is really odd nitpicks