Java performance: Difference between revisions

Revision as of 14:59, 13 December 2020

Latest revision as of 05:07, 14 August 2025

(48 intermediate revisions by 26 users not shown)

Line 1:

{{Short description|Aspect of Java programming language}}

{{Dablink|This article is a general presentation of the [[Java (software platform)|Java platform]] performance. For criticisms about Java performance, and more generally about the [[Java (programming language)|Java language]], see [[Criticism of Java]].}}

{{Update|reason=Is missing the many improvements in Java 8, 11, 17, 21, ... |date=November 2023}}

{{Use mdy dates|date=October 2018}}

In [[software development]], the programming language [[Java (programming language)|Java]] was historically considered slower than the fastest [[ProgrammingThird-generation languageprogramming generationslanguage|3rd third-generation]] [[Type system|typed]] languages such as [[C (programming language)|C]] and [[C++]].<ref>{{Cite web|url=http://www.scribblethink.org/Computer/javaCbenchmark.html|title=Java versus C++ benchmarks}}</ref> TheIn maincontrast reasonto beingthose a different language designlanguages, whereJava after compiling, Javacompiles programsby rundefault onto a [[Java virtualVirtual machineMachine]] (JVM) ratherwith thanoperations directlydistinct onfrom those of the actual computer's [[centralhardware. processorEarly unit|processor]]JVM asimplementations were [[nativeInterpreter code(computing)|interpreters]],; asthey dosimulated Cthe andvirtual C++operations programs.one-by-one Performancerather wasthan atranslating matterthem ofinto concern[[machine becausecode]] muchfor business software has been written in Java after the language quickly became popular in the late 1990s anddirect earlyhardware 2000sexecution.

Since the late 1990s, the execution speed of Java programs improved significantly via introduction of [[just-in-time compilation]] (JIT) (in 1997 for [[Java version history|Java 1.1]]),<ref name="symantec.comSymantec">{{Cite web

| url=http://www.symantec.com/about/news/release/article.jsp?prid=19970407_03

| archive-url=https://web.archive.org/web/20100628171748/http://www.symantec.com/about/news/release/article.jsp?prid=19970407_03

| url-status=dead

| archive-date=June 28, 2010

| title=Symantec's Just-In-Time Java Compiler To Be Integrated Into Sun JDK 1.1

}}</ref><ref name=cnet1998/><ref>{{cite web

| url=http://grnlight.net/index.php/programming-articles/116-java-gets-four-times-faster-with-new-symantec-just-in-time-compiler

| archive-url=https://archive.today/20140527181040/http://grnlight.net/index.php/programming-articles/116-java-gets-four-times-faster-with-new-symantec-just-in-time-compiler

| title=Java gets four times faster with new Symantec just-in-time compiler}}</ref> the addition of language features supporting better code analysis, and optimizations in the JVM (such as [[HotSpot (virtual machine)|HotSpot]] becoming the default for [[Sun Microsystems|Sun]]'s JVM in 2000). Hardware execution of Java bytecode, such as that offered by ARM's [[Jazelle]], was also explored to offer significant performance improvements.

| url-status=usurped

| archive-date=May 27, 2014

| title=Java gets four times faster with new Symantec just-in-time compiler}}</ref> the addition of language features supporting better code analysis, and optimizations in the JVM (such as [[HotSpot (virtual machine)|HotSpot]] becoming the default for [[Sun Microsystems|Sun]]'s JVM in 2000). Sophisticated [[garbage collection (computer science)|garbage collection]] strategies were also an area of improvement. Hardware execution of Java bytecode, such as that offered by ARM's [[Jazelle]], was also explored to offer significantbut performancenot improvementsdeployed.

The [[Computer performance|performance]] of a [[Java bytecode]] compiled Java program depends on how optimally its given tasks are managed by the host [[Java virtual machine]] (JVM), and how well the JVM exploits the features of the [[computer hardware]] and [[operating system]] (OS) in doing so. Thus, any Java [[Software performance testing|performance test]] or comparison has to always report the version, vendor, OS and hardware architecture of the used JVM. In a similar manner, the performance of the equivalent natively compiled program will depend on the quality of its generated machine code, so the test or comparison also has to report the name, version and vendor of the used compiler, and its activated [[compiler optimization]] directives.

==Virtual machine optimization methods==

Many optimizations have improved the performance of the JVM over time. However, although Java was often the first [[Virtualvirtual machine]] to implement them successfully, they have often been used in other similar platforms as well.

===Just-in-time compiling===

{{Further|Just-in-time compilation|HotSpot (virtual machine)}}

Early JVMs always interpreted [[Java bytecode]]s. This had a large performance penalty of between a factor 10 and 20 for Java versus C in average applications.<ref>{{cite web | url=http://www.shudo.net/jit/perf/ | title=Performance Comparison of Java/.NET Runtimes (Oct 2004) }}</ref> To combat this, a just-in-time (JIT) compiler was introduced into Java 1.1. Due to the high cost of compiling, an added system called [[HotSpot (virtual machine)|HotSpot]] was introduced in Java 1.2 and was made the default in Java 1.3. Using this framework, the [[Java virtual machine]] continually analyses program performance for ''hot spots'' which are executed frequently or repeatedly. These are then targeted for [[Optimization (computer science)|optimizing]], leading to high performance execution with a minimum of [[Overhead (computing)|overhead]] for less performance-critical code.<ref>

{{Cite web

| url=https://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_dive_into.html

Line 25 ⟶ 32:

| first=Kohsuke

| date=March 30, 2008

| accessdateaccess-date=April 2, 2008

| archive-url=https://web.archive.org/web/20080402034758/http://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_dive_into.html

| archive-date=April 2, 2008

Line 35 ⟶ 42:

| title=Fast, Effective Code Generation in a Just-In-Time Java Compiler

| publisher=[[Intel Corporation]]

| accessdateaccess-date=June 22, 2007}}</ref>

Some benchmarks show a 10-fold speed gain by this means.<ref>This [http://www.shudo.net/jit/perf/ article] shows that the performance gain between interpreted mode and Hotspot amounts to more than a factor of 10.</ref> However, due to time constraints, the compiler cannot fully optimize the program, and thus the resulting program is slower than native code alternatives.<ref>[http://www.itu.dk/~sestoft/papers/numericperformance.pdf Numeric performance in C, C# and Java ]</ref><ref>[http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf Algorithmic Performance Comparison Between C, C++, Java and C# Programming Languages] {{webarchive|url=https://web.archive.org/web/20100331155325/http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf |date=March 31, 2010 }}</ref>

===Adaptive optimizing===

Line 46 ⟶ 53:

| title=The Java HotSpot Virtual Machine, v1.4.1

| publisher=[[Sun Microsystems]]

| accessdateaccess-date=April 20, 2008}}</ref><ref>{{Cite web

| url=httphttps://headius.blogspot.com/2008/01/langnet-2008-day-1-thoughts.html

| title=Lang.NET 2008: Day 1 Thoughts

| quote=''Deoptimization is very exciting when dealing with performance concerns, since it means you can make much more aggressive optimizations...knowing you'll be able to fall back on a tried and true safe path later on''

| last=Nutter|first=Charles

| date=January 28, 2008

| accessdateaccess-date=January 18, 2011}}</ref>

===Garbage collection===

Line 66 ⟶ 73:

====Split bytecode verification====

Before executing a [[Class (computer science)|class]], the Sun JVM verifies its [[Java bytecode]]s (see [[Java virtual machine#Bytecode verifier|bytecode verifier]]). This verification is performed lazily: classes' bytecodes are only loaded and verified when the specific class is loaded and prepared for use, and not at the beginning of the program. (Other verifiers, such as the Java/400 verifier for [[IBM]] [[iSeries]] (System i), can perform most verification in advance and cache verification information from one use of a class to the next.) However, as the Java [[Java Platform#Class libraries|class libraries]] are also regular Java classes, they must also be loaded when they are used, which means that the start-up time of a Java program is often longer than for [[C++]] programs, for example.

A method named ''split-time verification'', first introduced in the [[Java Platform, Micro Edition]] (J2ME), is used in the JVM since [[Java version history|Java version 6]]. It splits the verification of [[Java bytecode]] in two phases:<ref>{{cite web

Line 72 ⟶ 79:

|title = New Java SE 6 Feature: Type Checking Verifier

|publisher = Java.net

|accessdateaccess-date = January 18, 2011

}}{{dead link|date=November 2017 |bot=InternetArchiveBot |fix-attempted=yes }}</ref>

*Design-time – when compiling a class from source to bytecode

Line 81 ⟶ 88:

====Escape analysis and lock coarsening====

{{Further|Lock (computer science)|Escape analysis}}

Java is able to manage [[Thread (computer science)|multithreading]] at the language level. Multithreading is a method allowingallows programs to perform multiple processes concurrently, thus producingimproving fasterthe performance for programs running on [[computer system]]s with multiple processors or cores. Also, a multithreaded application can remain responsive to input, even while performing long running tasks.

However, programs that use multithreading need to take extra care of [[Object (computer science)|objects]] shared between threads, locking access to shared [[Method (computer science)|methods]] or [[block (programming)|blocks]] when they are used by one of the threads. Locking a block or an object is a time-consuming operation due to the nature of the underlying [[operating system]]-level operation involved (see [[concurrency control]] and [[Lock (computer science)#Granularity|lock granularity]]).

Line 87 ⟶ 94:

As the Java library does not know which methods will be used by more than one thread, the standard library always locks [[block (programming)|blocks]] when needed in a multithreaded environment.

Before Java 6, the virtual machine always [[Lock (computer science)|locked]] objects and blocks when asked to by the program, even if there was no risk of an object being modified by two different threads at once. For example, in this case, a local {{code|vectorVector}} was locked before each of the ''add'' operations to ensure that it would not be modified by other threads (vector{{code|Vector}} is synchronized), but because it is strictly local to the method this is needless:

<syntaxhighlight lang="java">

public String getNames() {

final Vector<String> v = new Vector<>();

v.add("Me");

v.add("You");

Line 103 ⟶ 110:

|author=Brian Goetz

|date=October 18, 2005

|accessdateaccess-date=January 26, 2013}}</ref> so in the above case, the virtual machine would not lock the Vector object at all.

Since version 6u23, Java includes support for escape analysis.<ref>{{cite web

Line 110 ⟶ 117:

|publisher=[[Oracle Corporation]]

|quote=''Escape analysis is a technique by which the Java Hotspot Server Compiler can analyze the scope of a new object's uses and decide whether to allocate it on the Java heap. Escape analysis is supported and enabled by default in Java SE 6u23 and later.''

|accessdateaccess-date=January 14, 2014}}</ref>

====Register allocation improvements====

Before [[Java version history|Java 6]], [[Register allocation|allocation of registers]] was very primitive in the ''client'' virtual machine (they did not live across [[Block (programming)|blocks]]), which was a problem in [[CPU design]]s which had fewer [[processor register]]s available, as in [[x86]]s. If there are no more registers available for an operation, the compiler must [[register spilling|copy from register to memory]] (or memory to register), which takes time (registers are significantly faster to access). However, the ''server'' virtual machine used a [[Graph coloring|color-graph]] allocator and did not have this problem.

An optimization of register allocation was introduced in Sun's JDK 6;<ref>[http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6320351 Bug report: new register allocator, fixed in Mustang (JDK 6) b59]</ref> it was then possible to use the same registers across blocks (when applicable), reducing accesses to the memory. This led to a reported performance gain of about 60% in some benchmarks.<ref>[http://weblogs.java.net/blog/2005/11/10/mustangs-hotspot-client-gets-58-faster Mustang's HotSpot Client gets 58% faster!] {{Webarchive|url=https://web.archive.org/web/20120305215143/http://weblogs.java.net/blog/2005/11/10/mustangs-hotspot-client-gets-58-faster |date=March 5, 2012 }} in Osvaldo Pinali Doederlein's Blog at java.net</ref>

====Class data sharing====

Line 124 ⟶ 131:

==History of performance improvements==

{{Update|section|date=April 2023|reason=The most recently mentioned version in this section, Java 7, is over a decade old; as of writing, Java 20 is the current version}}

{{Further|Java version history}}

Apart from the improvements listed here, each release of Java introduced many performance improvements in the JVM and Java [[application programming interface]] (API).

JDK 1.1.6: First [[just-in-time compilation]] ([[NortonLifeLock|Symantec]]'s JIT-compiler)<ref name="symantec.comSymantec"/><ref name="symantec compiler">{{Cite web|last1=Mckay|first1=Niali|url=http://linxdigital.ca/java-four-times-faster-symantec-compiler.html|title=Java gets four times faster with new Symantec just-in-time compiler}}</ref>

J2SE 1.2: Use of a [[Garbage collection (computer science)#Generational GC (aka Ephemeral GC)|generational collector]].

Line 154 ⟶ 162:

| publisher=Sun Microsystems

|last=Haase|first=Chet

| quote=''At the OS level, all of these megabytes have to be read from disk, which is a very slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not. So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity.''

|date= May 2007| accessdateaccess-date=July 27, 2007}}</ref>

*Parts of the platform needed to execute an application accessed from the web when JRE is not installed are now downloaded first. The full JRE is 12 MB, a typical Swing application only needs to download 4 MB to start. The remaining parts are then downloaded in the background.<ref>{{Cite web

| url=http://java.sun.com/developer/technicalArticles/javase/consumerjre#JavaKernel

Line 161 ⟶ 169:

| publisher=Sun Microsystems

| last=Haase|first=Chet

|date= May 2007| accessdateaccess-date=July 27, 2007}}</ref>

*Graphics performance on [[Microsoft Windows|Windows]] improved by extensively using [[Direct3D]] by default,<ref>{{Cite web|url=http://java.sun.com/developer/technicalArticles/javase/consumerjre#Performance|title=Consumer JRE: Leaner, Meaner Java Technology|publisher=Sun Microsystems|last=Haase|first=Chet|date= May 2007|accessdateaccess-date=July 27, 2007}}</ref> and use [[shader]]s on [[graphics processing unit]] (GPU) to accelerate complex [[Java 2D]] operations.<ref>{{Cite web|url=https://weblogs.java.net/blog/campbell/archive/2007/04/faster_java_2d.html|title=Faster Java 2D Via Shaders|last=Campbell|first=Chris|date=April 7, 2007|accessdateaccess-date=January 18, 2011|archive-url=https://web.archive.org/web/20110605111343/http://weblogs.java.net/blog/campbell/archive/2007/04/faster_java_2d.html|archive-date=June 5, 2011|url-status=dead|df=mdy-all}}</ref>

===Java 7===

Line 171 ⟶ 179:

| publisher=Sun Microsystems

|last=Haase|first=Chet

|date= May 2007| accessdateaccess-date=July 27, 2007}}</ref>

*Provide JVM support for [[dynamic programming language]]s, following the prototyping work currently done on the [[Da Vinci Machine]] (Multi Language Virtual Machine),<ref>{{Cite web

| url=http://www.jcp.org/en/jsr/detail?id=292

| title=JSR 292: Supporting Dynamically Typed Languages on the Java Platform

| publisher=jcp.org

| accessdateaccess-date=May 28, 2008}}</ref>

*Enhance the existing concurrency library by managing [[parallel computing]] on [[multi-core]] processors,<ref>{{Cite web

| url=http://www.ibm.com/developerworks/java/library/j-jtp03048.html?ca

| title=Java theory and practice: Stick a fork in it, Part 2

| last=Goetz|first=Brian

| website=[[IBM]]

| date=March 4, 2008

| accessdateaccess-date=March 9, 2008}}</ref><ref>{{Cite web

| url=http://www.infoq.com/news/2008/03/fork_join

| title=Parallelism with Fork/Join in Java 7

Line 188 ⟶ 197:

| publisher=infoq.com

| date=March 21, 2008

| accessdateaccess-date=May 28, 2008}}</ref>

*Allow the JVM to use both the ''[[HotSpot (virtual machine)#Features|client]]'' and ''server'' [[Just-in-time compilation|JIT compilers]] in the same session with a method called tiered compiling:<ref>{{Cite web

| url=http://developers.sun.com/learning/javaoneonline/2006/coreplatform/TS-3412.pdf

| title=New Compiler Optimizations in the Java HotSpot Virtual Machine

| publisher=Sun Microsystems

|date= May 2006| accessdateaccess-date=May 30, 2008}}</ref>

**The ''client'' would be used at startup (because it is good at startup and for small applications),

**The ''server'' would be used for long-term running of the application (because it outperforms the ''client'' compiler for this).

Line 202 ⟶ 211:

| last=Humble|first=Charles

| date=May 13, 2008

| accessdateaccess-date=September 7, 2008

}}</ref><ref>

{{Cite web

Line 210 ⟶ 219:

| first=Danny

| date=November 12, 2008

| accessdateaccess-date=November 15, 2008

| archive-url=https://web.archive.org/web/20111208114910/http://blogs.oracle.com/theplanetarium/entry/java_vm_trying_a_new

| archive-date=December 8, 2011

Line 219 ⟶ 228:

==Comparison to other languages==

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. The target [[Platform (computing)|platform]] of Java's [[bytecode]] compiler is the [[Java platform]], and the bytecode is either interpreted or compiled into machine code by the JVM. Other compilers almost always target a specific hardware and software platform, producing machine code that will stay virtually unchanged during execution{{citation needed|reason=What are the real world, non-theoretical implications of this?|date=May 2016}}. Very different and hard-to-compare scenarios arise from these two different approaches: static vs. [[dynamic compilation]]s and [[Dynamic recompilation|recompilations]], the availability of precise information about the runtime environment and others.

Java is often [[Just-in-time compilation|compiled just-in-time]] at runtime by the Java [[virtual machine]], but may also be [[Ahead-of-time compilation|compiled ahead-of-time]], as is C++. When compiled just-in-time, the micro-benchmarks of [[The Computer Language Benchmarks Game]] indicate the following about its performance:<ref>

Line 226 ⟶ 235:

| title=Computer Language Benchmarks Game

| publisher=benchmarksgame.alioth.debian.org

| accessdateaccess-date=June 2, 2011

| archive-url=https://web.archive.org/web/20150125100238/http://benchmarksgame.alioth.debian.org/u32q/which-programs-are-fastest.html

| archive-date=January 25, 2015

Line 237 ⟶ 246:

| title=Computer Language Benchmarks Game

| publisher=benchmarksgame.alioth.debian.org

| accessdateaccess-date=June 2, 2011

| archive-url=https://web.archive.org/web/20150113040554/http://benchmarksgame.alioth.debian.org/u64q/java.html

| archive-date=January 13, 2015

Line 246 ⟶ 255:

| title=Computer Language Benchmarks Game

| publisher=benchmarksgame.alioth.debian.org

| accessdateaccess-date=June 2, 2011

| archive-url=https://web.archive.org/web/20150110034032/http://benchmarksgame.alioth.debian.org/u64q/csharp.html

| archive-date=January 10, 2015

Line 255 ⟶ 264:

| title=Computer Language Benchmarks Game

| publisher=benchmarksgame.alioth.debian.org

| accessdateaccess-date=June 2, 2011

| archive-url=https://web.archive.org/web/20150102034407/http://benchmarksgame.alioth.debian.org/u64q/python.html

| archive-date=January 2, 2015

Line 265 ⟶ 274:

Benchmarks often measure performance for small numerically intensive programs. In some rare real-life programs, Java out-performs C. One example is the benchmark of [[Jake2]] (a clone of [[Quake II]] written in Java by translating the original [[GPL]] C code). The Java 5.0 version performs better in some hardware configurations than its C counterpart.<ref>: 260/250 [[Frame rate|frame/s]] versus 245 frame/s (see [http://www.bytonic.de/html/benchmarks.html benchmark])</ref> While it is not specified how the data was measured (for example if the original Quake II executable compiled in 1997 was used, which may be considered bad as current C compilers may achieve better optimizations for Quake), it notes how the same Java source code can have a huge speed boost just by updating the VM, something impossible to achieve with a 100% static approach.

For other programs, the C++ counterpart can, and usually does, run significantly faster than the Java equivalent. A benchmark performed by Google in 2011 showed a factor 10 between C++ and Java.<ref>{{Cite journal |last1=Hundt |first1=Robert |title=Loop Recognition in C++/Java/Go/Scala |workjournal=Scala Days 2011 |___location=Stanford, California |publisher=[[Google]] |accessdateaccess-date=March 23, 2014 |url=https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf}}</ref> At the other extreme, an academic benchmark performed in 2012 with a 3D modelling algorithm showed the [[Java 6]] JVM being from 1.09 to 1.91 times slower than C++ under Windows.<ref>{{cite web

| url= http://www.best-of-robotics.org/pages/publications/gherardi12java.pdf

| title=A Java vs. C++ performance evaluation: a 3D modeling benchmark

Line 271 ⟶ 280:

|author1=L. Gherardi |author2=D. Brugali |author3=D. Comotti | year= 2012

| quote=''Using the Server compiler, which is best tuned for long-running applications, have instead demonstrated that Java is from 1.09 to 1.91 times slower(...)In conclusion, the results obtained with the server compiler and these important features suggest that Java can be considered a valid alternative to C++''

| accessdateaccess-date= March 23, 2014}}</ref>

Some optimizations that are possible in Java and similar languages may not be possible in certain circumstances in C++:<ref name="idiom">{{Cite web|url=http://scribblethink.org/Computer/javaCbenchmark.html |title=Performance of Java versus C++ |publisher=Computer Graphics and Immersive Technology Lab, University of Southern California| author=Lewis, J.P. |author2=Neumann, Ulrich}}</ref>

Line 282 ⟶ 291:

| title=The Java HotSpot Performance Engine: Method Inlining Example

| publisher=[[Oracle Corporation]]

| accessdateaccess-date=June 11, 2011}}</ref><ref>{{Cite web

| url=http://blog.headius.com/2008/05/power-of-jvm.html

| title=The Power of the JVM

Line 288 ⟶ 297:

| last=Nutter|first=Charles

| quote=''What happens if you've already inlined A's method when B comes along? Here again the JVM shines. Because the JVM is essentially a dynamic language runtime under the covers, it remains ever-vigilant, watching for exactly these sorts of events to happen. And here's the really cool part: when situations change, the JVM can deoptimize. This is a crucial detail. Many other runtimes can only do their optimization once. C compilers must do it all ahead of time, during the build. Some allow you to profile your application and feed that into subsequent builds, but once you've released a piece of code it's essentially as optimized as it will ever get. Other VM-like systems like the CLR do have a JIT phase, but it happens early in execution (maybe before the system even starts executing) and doesn't ever happen again. The JVM's ability to deoptimize and return to interpretation gives it room to be optimistic...room to make ambitious guesses and gracefully fall back to a safe state, to try again later.''

| accessdateaccess-date=June 11, 2011}}</ref>

Results for [[Benchmark (computing)|microbenchmarks]] between Java and C++ highly depend on which operations are compared. For example, when comparing with Java 5.0:

*32- and 64 -bit arithmetic operations,<ref>{{Cite web

| url=http://www.ddj.com/java/184401976?pgno=2

| title=Microbenchmarking C++, C#, and Java: 32-bit integer arithmetic

| publisher=[[Dr. Dobb's Journal]]

| date=July 1, 2005

| accessdateaccess-date=January 18, 2011}}</ref><ref>{{Cite web

| url=http://www.ddj.com/java/184401976?pgno=12

| title=Microbenchmarking C++, C#, and Java: 64-bit double arithmetic

| publisher=[[Dr. Dobb's Journal]]

| date=July 1, 2005

| accessdateaccess-date=January 18, 2011}}</ref> [[Input/output|Filefile Iinput/Ooutput]], <ref>{{Cite web

| url=http://www.ddj.com/java/184401976?pgno=15

| title=Microbenchmarking C++, C#, and Java: File I/O

| publisher=[[Dr. Dobb's Journal]]

| date=July 1, 2005

| accessdateaccess-date=January 18, 2011}}</ref> and [[Exceptionexception handling]],<ref>{{Cite web

| url=http://www.ddj.com/java/184401976?pgno=17

| title=Microbenchmarking C++, C#, and Java: Exception

| publisher=[[Dr. Dobb's Journal]]

| date=July 1, 2005

| accessdateaccess-date=January 18, 2011}}</ref> have a similar performance to comparable C++ programs

*Operations on [[Array data type|Arrayarray]]s<ref>{{Cite web

| url=http://www.ddj.com/java/184401976?pgno=19

| title=Microbenchmarking C++, C#, and Java: Array

| publisher=[[Dr. Dobb's Journal]]

| date=July 1, 2005

| accessdateaccess-date=January 18, 2011}}</ref> operationshave better performance are better in C.

*The performance of [[Trigonometrictrigonometric functions]] performance is much better in C.<ref>{{Cite web

| url=http://www.ddj.com/java/184401976?pgno=19

| title=Microbenchmarking C++, C#, and Java: Trigonometric functions

| publisher=[[Dr. Dobb's Journal]]

| date=July 1, 2005

| accessdateaccess-date=January 18, 2011}}</ref>

----

Line 330 ⟶ 339:

===Multi-core performance===

The scalability and performance of Java applications on multi-core systems is limited by the object allocation rate. This effect is sometimes called an "allocation wall".<ref>Yi Zhao, Jin Shi, Kai Zheng, Haichuan Wang, Haibo Lin and Ling Shao, [http://portal.acm.org/citation.cfm?id=1640116 Allocation wall: a limiting factor of Java applications on emerging multi-core platforms], Proceedings of the 24th ACM SIGPLAN conference on Object oriented programming systems languages and applications, 2009.</ref> However, in practice, modern garbage collector algorithms use multiple cores to perform garbage collection, which to some degree alleviates this problem. Some garbage collectors are reported to sustain allocation rates of over a gigabyte per second,<ref>[{{Cite web |url=http://www.azulsystems.com/sites/default/files/images/c4_paper_acm_0.pdf |title=C4: The Continuously Concurrent Compacting Collector] |access-date=October 29, 2013 |archive-date=August 9, 2014 |archive-url=https://web.archive.org/web/20140809222603/http://www.azulsystems.com/sites/default/files/images/c4_paper_acm_0.pdf |url-status=dead }}</ref> and there exist Java-based systems that have no problems scaling to several hundreds of CPU cores and heaps sized several hundreds of GB.<ref>[https://www.theregister.co.uk/2007/06/15/azul_releases_7200_systems/ Azul bullies Java with 768 core machine]</ref>

Automatic memory management in Java allows for efficient use of lockless and immutable data structures that are extremely hard or sometimes impossible to implement without some kind of a garbage collection.{{citation needed|date=September 2018}} Java offers a number of such high-level structures in its standard library in the java.util.concurrent package, while many languages historically used for high performance systems like C or C++ are still lacking them.{{citation needed|date=September 2017}}

Line 347 ⟶ 356:

|title = How fast is the new verifier?

|date = February 7, 2006

|accessdateaccess-date = May 9, 2007

|url-status = dead

|archiveurlarchive-url = https://web.archive.org/web/20060516011057/http://forums.java.net/jive/thread.jspa?messageID=94530

|archivedatearchive-date = May 16, 2006

|df = dmy-all

}}</ref>

Line 365 ⟶ 374:

{{Disputed section|Most_of_the_memory_use_section_is_really_odd_nitpicks|date=August 2019}}

Java memory use is much higher than C++'s memory use because:

*There is an overhead of 8 bytes for each object and 12 bytes for each array<ref>{{Cite web|url=http://www.javamex.com/tutorials/memory/object_memory_usage.shtml|title = How to calculate the memory usage of Java objects}}</ref> in Java. If the size of an object is not a multiple of 8 bytes, it is rounded up to next multiple of 8. This means an object holding one byte field occupies 16 bytes and needs a 4-byte reference. C++ also allocates a [[Pointer (computer programming)|pointer]] (usually 4 or 8 bytes) for every object which class directly or indirectly declares [[virtual function]]s.<ref>{{cite web |url=http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=195 |title=ArchivedInformIT: C++ Reference Guide > the Object copyModel |accessdateaccess-date=June 22, 2009 |url-status=dead |archiveurlarchive-url=https://web.archive.org/web/20080221131118/http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=195 |archivedatearchive-date=February 21, 2008 |df=dmy-all }}</ref>

*Lack of address arithmetic makes creating memory-efficient containers, such as tightly spaced structures and [[XOR linked list]]s, currently impossible ([[Project Valhalla (Java language)|the OpenJDK Valhalla project]] aims to mitigate these issues, though it does not aim to introduce pointer arithmetic; this cannot be done in a garbage collected environment).

*Contrary to malloc and new, the average performance overhead of garbage collection asymptotically nears zero (more accurately, one CPU cycle) as the heap size increases.<ref>https://www.youtube.com/watch?v=M91w0SBZ-wc : Understanding Java Garbage Collection - a talk by Gil Tene at JavaOne</ref>

*Parts of the [[Java Class Library]] must load before program execution (at least the classes used within a program).<ref>{{Cite web|url=http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html|title = .: ToMMTi-Systems :: Hinter den Kulissen moderner 3D-Hardware}}</ref> This leads to a significant memory overhead for small applications.{{citation needed|date=January 2012}}

*Both the Java binary and native recompilations will typically be in memory.

*The virtual machine uses substantial memory.

Line 380 ⟶ 389:

| title= Math (Java Platform SE 6)

| publisher= [[Sun Microsystems]]

| accessdateaccess-date=June 8, 2008

}}</ref> On the [[x87]] floating point subset, Java since 1.4 does argument reduction for sin and cos in software,<ref>

{{Cite web

| url=http://blogs.oracle.com/jag/entry/transcendental_meditation

| title=Transcendental Meditation

| accessdateaccess-date=June 8, 2008

| date=July 27, 2005

| first=James

Line 397 ⟶ 406:

| url=http://www.osnews.com/story/5602&page=3

| title=Nine Language Performance Round-up: Benchmarking Math & File I/O

| last=W. Cowell-Shah

| first=Christopher W.

| date=January 8, 2004

| accessdateaccess-date=June 8, 2008

| archive-url=https://web.archive.org/web/20181011222232/http://www.osnews.com/story/5602%26page%3D3

| archive-date=October 11, 2018

| url-status=dead

}}</ref>{{clarify|date=April 2016}}

JDK (11 and above) has a significant progress in the speed of evaluation of trigonometric functions compared to JDK 8.<ref>S. V. Chekanov, G. Gavalian, N. A. Graf, Jas4pp - a Data-Analysis Framework for Physics and Detector Studies, (2020), (https://arxiv.org/abs/2011.05329) (2020) ANL-HEP-164101, SLAC-PUB-17569</ref>

===Java Native Interface===

Line 415 ⟶ 423:

| publisher=[[Sun Microsystems]]

| year=2001

| accessdateaccess-date=February 15, 2008}}

</ref><ref>{{Cite web

|url = httphttps://janet-project.sourceforge.net/papers/jnibench.pdf

|title = Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark

|last = Kurzyniec

|first = Dawid

|author2 = Vaidy Sunderam

|accessdateaccess-date = February 15, 2008

|url-status = dead

|archiveurlarchive-url = https://web.archive.org/web/20050214080519/http://janet-project.sourceforge.net/papers/jnibench.pdf

|archivedatearchive-date = February 14, 2005

|df = dmy-all

}}</ref>{{sfn|Bloch|2018|loc=Chapter §11 Item 66: Use native methods judiciously|p=285}} [[Java Native Access]] (JNA) provides [[Java (programming language)|Java]] programs easy access to native [[Shared library|shared libraries]] ([[dynamic-link library]] (DLLs) on Windows) via Java code only, with no JNI or native code. This functionality is comparable to Windows' Platform/Invoke and [[Python (programming language)|Python's]] ctypes. Access is dynamic at runtime without code generation. But it has a cost, and JNA is usually slower than JNI.<ref>{{Cite web

|url = https://jna.dev.java.net/#performance

|title = How does JNA performance compare to custom JNI?

|publisher = [[Sun Microsystems]]

|accessdateaccess-date = December 26, 2009

}}{{dead link|date=November 2017 |bot=InternetArchiveBot |fix-attempted=yes }}</ref>

Line 443 ⟶ 451:

|date = May 10, 2005

|quote = ''It is hard to give a rule-of-thumb where SWT would outperform Swing, or vice versa. In some environments (e.g., Windows), SWT is a winner. In others (Linux, [[VMware]] hosting Windows), Swing and its redraw optimization outperform SWT significantly. Differences in performance are significant: factors of 2 and more are common, in either direction''

|accessdateaccess-date = May 24, 2008

|archive-url = https://web.archive.org/web/20080704103309/http://cosylib.cosylab.com/pub/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf

|archive-date = July 4, 2008

Line 456 ⟶ 464:

| quote=''We first perform some micro benchmarks for various JVMs, showing the overall good performance for basic arithmetic operations(...). Comparing this implementation with a Fortran/MPI one, we show that they have similar performance on computation intensive benchmarks, but still have scalability issues when performing intensive communications.''

|author1=Brian Amedro |author2=Vladimir Bodnartchouk |author3=Denis Caromel |author4=Christian Delbe |author5=Fabrice Huet |author6=Guillermo L. Taboada | publisher=[[INRIA]]

|date= August 2008 |accessdateaccess-date=September 9, 2008}}</ref>

However, high performance computing applications written in Java have won benchmark competitions. In 2008,<ref>{{Cite web

Line 464 ⟶ 472:

|author = Owen O'Malley - Yahoo! Grid Computing Team

|date = July 2008

|accessdateaccess-date = December 21, 2008

|url-status = dead

|archiveurlarchive-url = https://web.archive.org/web/20091015215436/http://developer.yahoo.net/blogs/hadoop/2008/07/apache_hadoop_wins_terabyte_sort_benchmark.html

|archivedatearchive-date = October 15, 2009

|df = dmy-all

}}

Line 478 ⟶ 486:

| date=May 11, 2009

| quote=''The hardware and operating system details are:(...)Sun Java JDK (1.6.0_05-b13 and 1.6.0_13-b03) (32 and 64 bit)''

| accessdateaccess-date=September 8, 2010

| publisher=[[CNET.com]]}}

</ref><ref>{{Cite web

Line 484 ⟶ 492:

| title=Hadoop breaks data-sorting world records

| date=May 15, 2009

| accessdateaccess-date=September 8, 2010

| publisher=[[CNET.com]]}}

</ref> an Apache [[Hadoop]] (an open-source high performance computing project written in Java) based cluster was able to sort a terabyte and petabyte of integers the fastest. The hardware setup of the competing systems was not fixed, however.<ref>{{cite web

| url=http://sortbenchmark.org/

| title=Sort Benchmark Home Page

|author1=Chris Nyberg |author2=Mehul Shah | accessdateaccess-date=November 30, 2010

}}</ref><ref name=googlemapreduce>{{cite web

| url=httphttps://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html

| title=Sorting 1PB with MapReduce

| publisher=google

| date=November 21, 2008

| accessdateaccess-date=December 1, 2010

| first=Grzegorz

| last=Czajkowski

Line 501 ⟶ 508:

===In programming contests===

Programs in Java start slower than those in other compiled languages.<ref>{{Cite web |url=http://topcoder.com/home/tco10/2010/06/08/algorithms-problem-writing/ |title=Archived copyTCO10 |access-date=June 21, 2010 |archive-url=https://web.archive.org/web/20101018212921/http://topcoder.com/home/tco10/2010/06/08/algorithms-problem-writing/ |archive-date=October 18, 2010 |url-status=dead |df=dmy-all }}</ref><ref>{{cite web | url=http://acm.timus.ru/help.aspx?topic=java&locale=en | title=How to write Java solutions @ Timus Online Judge }}</ref> Thus, some online judge systems, notably those hosted by Chinese universities, use longer time limits for Java programs<ref>{{cite web | url=http://acm.pku.edu.cn/JudgeOnline/faq.htm#q11 | title=FAQ }}</ref><ref>{{Cite web |url=http://acm.tju.edu.cn/toj/faq.html#qj |title=ArchivedFAQ &#124; TJU ACM-ICPC Online copyJudge |access-date=May 25, 2010 |archive-url=https://web.archive.org/web/20100629135921/http://acm.tju.edu.cn/toj/faq.html#qj |archive-date=June 29, 2010 |url-status=dead |df=mdy-all }}</ref><ref>{{cite web | url=http://www.codechef.com/wiki/faq#How_does_the_time_limit_work | title=FAQ &#124; CodeChef }}</ref><ref>{{Cite web |url=http://acm.xidian.edu.cn/land/faq |title=ArchivedHomePage copyof Xidian Univ. Online Judge |access-date=November 13, 2011 |archive-url=https://web.archive.org/web/20120219004452/http://acm.xidian.edu.cn/land/faq |archive-date=February 19, 2012 |url-status=dead |df=dmy-all }}</ref><ref>{{cite web | url=http://poj.org/faq.htm#q9 | title=FAQ }}</ref> to be fair to contestants using Java.

==See also==

Line 511 ⟶ 518:

*[[Java ConcurrentMap]]

==ReferencesCitations==

{{Reflist|2|refs=

<ref name=cnet1998>

{{cite news |url=http://www.cnet.com/news/short-take-apple-licenses-symantecs-just-in-time-compiler/

| title=Short Take: Apple licenses Symantec's just-in-time compiler |publisher= cnet.com

| date= May 12, 1998 |accessdateaccess-date= November 15, 2015}}</ref>

}}

==References==

*{{cite book |last=Bloch| first=Joshua| title= "Effective Java: Programming Language Guide" | publisher=Addison-Wesley | edition=third | isbn=978-0134685991| date=2018}}

==External links==