Java performance: Difference between revisions

Content deleted Content added
Arevxon (talk | contribs)
No edit summary
edit for sentence fragment, tense shift, factual inaccuracy
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 [[Programming language generations|3rd 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 afteris compiling, Javaspecified programsto runcompile onto a [[Java virtualVirtual machineMachine]] (JVM) ratherwith thanoperations distinct directlyfrom onthose 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 because much business software has been written in Java after the language quickly became popular in the latecode]] 1990sfor 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.com">{{Cite web
Line 10:
}}</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
| 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 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.