Talk:Java performance

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

"x times slower"[edit]

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)[reply]

Why can't something be 'x times slower' than something else? E.g. 40km/h is 2 times slower than 80 km/h. Tcotco (talk) 06:07, 21 July 2010 (UTC)[reply]

Even if "Foo is X times slower than Bar" is technically correct, it's easier for readers to understand "Bar is X times faster than Foo" or "Foo is an Xth as fast as Bar". --70.41.70.6 (talk) 05:28, 22 October 2010 (UTC)[reply]

It's not, because the expression "4 times slower than Y" is meaningless. "One times slower than Y" means "0% of Y". What on earth is "four times slower that Y"? It is better to say "25% the performance of Y". 40km/h is definitely not "2 times slower than 80km/h" as "2 times slower than 80km/h" is -160km/h. Or in your world is "2 times faster than 80km/h" the same as "120km/h"? :-) Kelt65 (talk) 00:04, 20 October 2016 (UTC)[reply]

Comparing C++ and Java is not that easy[edit]

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)[reply]

Sun vs Microsoft Windows[edit]

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)[reply]

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)[reply]

Need to differentiate Sun vs generic implementation[edit]

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)[reply]

Program Speed[edit]

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)

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)[reply]
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)[reply]
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)[reply]
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. [1] indicates that Java is 2 times slower. Can we change this statement? Tcotco (talk) 06:37, 20 July 2010 (UTC)[reply]


Escape analysis[edit]

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)[reply]

Casts[edit]

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)[reply]

"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)[reply]

References

  1. ^ http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php

Program Speed 2[edit]

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)[reply]

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)[reply]
I would like to see your unreferenced proof, not because it does not exist but because you probably misinterpreted it. The almost certain misinterpretations is that they measured characteristic X of java and C (via a benchmark) and you concluded characteristic Y ought be the same(Y is performance of Apps). Java has certain limitations (on purpose) (they took stuff out to make it) the is no (double * const) just a (const double *) (sorry I forget which means which, but java only has one of them, aka final Double). Anyway this amoungst other things has actual ramifications on speed when you design an app the size of a real world app, and endeavor to make it encapsulated, modularised, etal al. In java they have garbage collection no delete etc to relieve the programmer from the burden of worrying about such stuff. Show me the benchmark that measures the effect of only having const ptrs to char instead of ptrs to const chars.

Thrashing memory is a good way to lose performance, managing your implicit thrashing of memory is more challenging than in C++. Believe it or not the lack of a preprocessor is also speed challenging for java. In C/C++ #idef debug \n debug code \n #endif is h\ guaranteed to cost nothing in a release build, achieving similar functionality in java is a tad more challenging and if my mind is occupied by that tad there is that much less of it left over for worrying about optimal design for speed/functionality/maintainability.

Öhm?[edit]

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)[reply]

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)[reply]

Contradictory speed discussion[edit]

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)[reply]

Collections microbenchmarks[edit]

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)[reply]

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)[reply]

this page is clearly biased[edit]

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)[reply]

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)[reply]

Hervegirod: I also found this article to be biased. You had initially stated that Java is "generally just as fast as compiled languages such as C or C++" which is not supported by the reference you gave in that same sentence (i.e. the "shooutout"). Also it seems to dwell more on the theoretical reasons why Java might be faster than on the theoretical reasons why it might be slower or equivalent. I've fixed the first, but not the second. Tim Cooper Tcotco (talk) 06:15, 21 July 2010 (UTC)[reply]

This page is now close to being neutral. I think we should move some of content into Comparison of Java and C++, because there is much duplication. Alliumnsk (talk) 04:14, 30 August 2010 (UTC)[reply]

The way to use the page that note 42 refers to to describe that Java is faster than C in some cases is clearly cheat! The only one listed in that page that Java is faster than C is the 240 vs 260/250 fps one -- the Original C Code vs Jake2-0.9.4 JRE1.5 fastjogl/lwjgl. The speed of programs that using OpenGL is largely depended on OpenGL. Is OpenGL vs fastjogl (FAST java OpenGL) objective? It is just like to compare two codes which runs on 86 and i7 and says that the program that runs on i7 is faster. Jacob grace (talk) 22:06, 28 September 2015 (UTC)[reply]

A controversial paragraph[edit]

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)[reply]

Seems POV to me. Hervegirod (talk) 22:18, 9 June 2009 (UTC)[reply]

Additions in the introduction[edit]

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)[reply]


Introduction changed to clearly reflect this situation (it was implied) . Valenajarro (talk) 22:18, 9 June 2009 (UTC)[reply]

Article non-neutrality[edit]

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)[reply]

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)[reply]
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.
In 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)[reply]
While we're on the subject of garbage, the time taken to perform a garbage collect in some implementations depends on the number of objects allocated - so it is worth having fewer objects if speed is important. Stephen B Streater (talk) 23:02, 20 March 2010 (UTC)[reply]

Oh and by the way, wikipedia itself holds POV. A standard wikipedia POV(bias) is that it is possible to not inject your own bias and just reference sources and thus escape the need for expertise and judgment in the authors of authoritative articles(that POV in fact holds true surprisingly often). While that sentence is picking a rather large fight which I cant possibly win even if I am right, just suspend disbelief for paragraph or so and listen, because Im not picking fight with wikipedia just trying to point out rather large pothole that this wikipedia article may be about to fall into and make itself look sillier than the article already does. You wont find references or any objective measures that using Open Office, or eclipse feels like a laggy computer game, but it does, but with no cites you cant say it does. You can get citations saying compiled to assembly java (JIT compiler) is as fast as C, because it ought be just as fast for some tasks. Any task that can be elegantly expressed in java ought be ust as fast as C. If you manufacture a task that C aliasing of pointers makes the optimiser particularly confused the C or C++ compiled code may go slower than the java one. The fact that a good C++ programmer optimising for speed will never write it that way because it compiles slow has no effect on whether a benchmark will measure it as slower.

Thus if you guys who wish to move the article more in the direction of java is as fast as C want to start deleting anything without a citation, I have a dare for you. I dare you to find the citation that shows that any benchmark you cite is in anyway correlated with performance of a real world app written in that language. Thus any benchmarks that are not related to real world performance ought not be cited as they measure something other than what real people, readers of the article are interested in. Also benchmarks ought not be cited unless both version measure the same things, unfortunately you'll need actual expertise to know if thats true. One trap is the java code needs to have done enough work that the average cost of the garbage generated is largely amortised into the benchmark timing. As my wife is fond of saying i have not done my turn at cooking until I have also cleaned up. (Stuffing it all in a cupboard to be done later does not count) I posit that most people interested in finding out about the performance of language are not interested in finding language because they have benchmark they want executed quickly, but because they are choosing between, apps written in different languages. One reason I would want to know if java is slower than c++ is to know if my lovely compiler Eclipse, is written crap inside(it isnt) because it goes slow or thats just the penalty of being portable using java(it is).

Obvious non-sense[edit]

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)[reply]

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)[reply]
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)[reply]

Regarding memory access...the previous comment is on the right track but don't think about disk paging. Think about paging in and out of today's processor cache levels (i.e. L1, L2 and sometimes L3). Memory is brought into each layer in pages, not just the few bytes that may have been requested by the current processor instruction. If a generational GC can defragment the heap, there's a better chance adjacent objects will already exist and remain in some layer of processor cache vs. waiting for relatively slower access to off-processor memory. This will also reduce cache thrashing (where the next memory operation purges the last operation from the cache). Considering today's gigahertz speeds that are many, many multiples of memory bus speed, I would not underestimate this benefit to certain memory intensive work loads. Of course this doesn't mean a well-written C/C++ program cannot attempt to purposely manage it's memory in a way that also minimizes fragmentation. However, if the C/C++ program uses external libraries, it may be difficult to also optimize them whereas Java's optimization is systematic rather than intentional. Then again, since Java uses more memory and therefore raises the probability of thrashing the processor cache, a defragmenting GC may only be reclaiming part of the performance lost due to the larger memory footprint. — Preceding unsigned comment added by 24.217.229.216 (talk) 01:30, 6 August 2011 (UTC)[reply]

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).[reply]
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)[reply]

Revetred edits 23 August[edit]

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)[reply]

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)[reply]
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)[reply]

Programming contests[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Alliumnsk (talk) 13:00, 6 December 2010 (UTC)[reply]

Sort performance[edit]

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. [1] 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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

JIT vs. non-JIT vs. semantics[edit]

The article seems to pay way too much attention about mode of compilation. There is no necessity that Java programs are to be compiled to bytecode. It is equally possible to compile Java program to native code, and compile C/C++ program with MS' compiler using /clr:pure switch to CLR bytecode. More important differences is semantics... In C/C++, in code like x+=foo()+bar(); compiler may freely rearrange calls to foo and bar (in C, if you care about order, you just split it in several lines). In Java, compiler may rearrange calls to foo and bar only if it can PROVE (which is sometimes impossible) that it doesn't affect anything. And it has to save value of x before calling foo and bar unless it can prove foo and bar do not modify x. There is no way to tell Java compiler that order of execution is irrelevant. In Java, is it possible convert, say, Apple[] to Fruit[], but the cost of this is that every store operation in Fruit[] will be dynamically checked (otherwise someone could put a Pear in array should contain only Apple objects). In C++, equivalent conversion of Apple** to Fruit** is disallowed. Such differences are numerous and result in more differences than peephole optimizations.Alliumnsk (talk) 09:28, 23 October 2011 (UTC)[reply]

There are two reasons why Java JIT compiler can rearrange calls to foo and bar, first is because there are no pointers in java, making it easier for the compiler to prove that the reordering (or inlining) will not change anything, second is because of deoptimization, the JIT compiler can make aggressive optimizations based on assumptions (not proof), and deoptimize the code (un-JIT it) if it appear over the time that its assumptions were not true anymore. Concerning your Apple / Fruit example, arrays are objects not pointers in Java, so you are not allowed to put something which is not an Apple in an Apple array. In C/C++, you can put anything in it since an array is just a pointer. Hervegirod (talk) 17:18, 23 October 2011 (UTC)[reply]
In this example, it cannot be 'easier' because cost of this for C/C++ is zero. Aggressive (dangerous) optimizations, again, involve run-time check. "No pointers" is more a naming issue. In C, if you have struct complex { float re,im; }; and never take addresses of its fields - re and im (why would you?), but only take addresses of struct complex - you get the same "no pointers" situation as in Java. You miss the Apple/Fruit example entirely. Java disallows this only at run-time, inserting dynamic type-checks. C++ disallows at compile-time. Well you can still put a Pear in Apple array (do you even know how? a simple typecast won't work), but it violates the rules. For one thing you can be sure, there will be no dynamic check for that just because compiler wasn't clever enough to prove it is not necessary.
class aa {
	static class Fruit{}
	static class Apple extends Fruit{}
	static class Pear extends Fruit{}
	public static void main(String args[]) {
		Apple[] a = new Apple[7];
		Fruit[] b = a; // since we are downcasting, there is no need to type-check
		b[5]= new Pear(); // uh-oh! dynamic typecheck is hidden somewhere
	}
}

Alliumnsk (talk)

The fact that Java hides pointer semantics from the programmer means nothing about the underlying architecture. Actually, every object in Java is a pointer, wrapped in a shiny name "reference", except for the primitives.1exec1 (talk) 23:08, 25 October 2011 (UTC)[reply]

"In programming contests" section[edit]

The references in this section seem to be broken and/or 5+ years old; they also look to be primary. Anyone have better ones? If not, I suggest deletion. Chronodm (talk) 22:16, 27 October 2011 (UTC)[reply]

I agree: unless we find a source that states that "we give problem solutions in Java more/less time since Java is slower/faster", we should not include any information about these contests. 1exec1 (talk) 20:01, 29 October 2011 (UTC)[reply]
For lazy people: 3rd ref:

Concretely speaking, Java programs are allowed to run for THREE TIMES the time limit and are given another 150MS for each input file out of consideration for I/O efficiency.

4rd ref:

7. Since Java program runs slow, The time limit of each problem will be about twice of the original, and the memory limit is enlarged to 1024M. Notice it may not enough for some problems.
Or sometimes they give time limits separate for each problem, like that: http://opencup.ru/files/oca/gp1/problems-e.pdf - where time limits for Java solutions of problems C,D,G,I are 1.75-3.5 times more...Alliumnsk (talk) 07:18, 13 November 2011 (UTC)[reply]
I suggest you to read the references first. Dates: The first one, says This entry was posted by connect4 on Tuesday, June 8th, 2010 at 12:40 pm. at its bottom. In the second one, if you happen to get through first sentence, you can see date February, 2 2009, which indicates the source is newer that that, which doesn't fit into "5+ years" you mentioned. Now, would you delete links to Dr.Dobbs which are 6 years old? Alliumnsk (talk) 06:54, 13 November 2011 (UTC)[reply]

Program speed Collections bullet point[edit]

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)[reply]

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)[reply]

Memory overhead source[edit]

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)[reply]

Hervegirod (talk) 23:23, 5 January 2012 (UTC)[reply]

Compiler optimizations category[edit]

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)[reply]

removing POV tag with no active discussion per Template:POV[edit]

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:
  1. There is consensus on the talkpage or the NPOV Noticeboard that the issue has been resolved
  2. It is not clear what the neutrality issue is, and no satisfactory explanation has been given
  3. 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)[reply]

Citations saying JNI is slow are very old[edit]

One of them is explicitly from 2001, and the other had no explicit date I could find but mentioned some of its tests as being performed under Windows 98.

These citations do not give me confidence that this is still the case, and I would recommend the section be updated, or at least that a {{Update|inaccurate=yes}} tag be added to the section.

Program Speed, the quake comparison[edit]

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)[reply]

Blacklisted Links Found on the Main Page[edit]

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)[reply]

Self-contradictory Information in Summary and Body[edit]

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) — Preceding unsigned comment added by 70.167.172.2 (talk)

Reference 4[edit]

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)[reply]

First sentence of "Comparison to other languages"[edit]

"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)[reply]

"Other compilers almost always target a specific hardware and software platform, producing machine code that will stay virtually unchanged during execution. "[edit]

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)[reply]

"Speed" ?[edit]

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)[reply]

External links modified[edit]

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:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:21, 22 November 2017 (UTC)[reply]

Most of the memory use section is really odd nitpicks[edit]

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)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Java_performance&oldid=1203076954"