Content deleted Content added
m HTTP to HTTPS for Blogspot |
|||
| (7 intermediate revisions by 6 users not shown) | |||
Line 3:
{{Use mdy dates|date=October 2018}}
In [[software development]], the programming language [[Java (programming language)|Java]] was historically considered slower than the fastest [[
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="
| 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). Sophisticated [[garbage collection]] strategies were also an area of improvement. Hardware execution of Java bytecode, such as that offered by ARM's [[Jazelle]], was explored but not deployed.▼
| 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 explored but not deployed.
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.
Line 48 ⟶ 54:
| publisher=[[Sun Microsystems]]
| access-date=April 20, 2008}}</ref><ref>{{Cite web
| url=
| 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''
Line 129 ⟶ 135:
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="
J2SE 1.2: Use of a [[Garbage collection (computer science)#Generational GC (aka Ephemeral GC)|generational collector]].
Line 304 ⟶ 310:
| publisher=[[Dr. Dobb's Journal]]
| date=July 1, 2005
| access-date=January 18, 2011}}</ref> [[Input/output|file input/output]], <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
| access-date=January 18, 2011}}</ref> and [[exception handling]]
| url=http://www.ddj.com/java/184401976?pgno=17
| title=Microbenchmarking C++, C#, and Java: Exception
Line 333 ⟶ 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>
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 419 ⟶ 425:
| access-date=February 15, 2008}}
</ref><ref>{{Cite web
|url =
|title = Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark
|last = Kurzyniec
Line 493 ⟶ 499:
|author1=Chris Nyberg |author2=Mehul Shah | access-date=November 30, 2010
}}</ref><ref name=googlemapreduce>{{cite web
| url=
| title=Sorting 1PB with MapReduce
| date=November 21, 2008
| |||