Javaの性能
C形式のポインタは、ポインタをサポートする言語での最適化を困難にする。
コードがプログラムの実行前にコンパイルされるため、#適応的コンパイルは完全にコンパイルされたコードでは実施できず、アーキテクチャの機能や、コードパスを用いた最適化の恩恵を受けられない。いくつかのベンチマークの結果は、C/C++の性能はプロセッサアーキテクチャに対応したコンパイルオプション(たとえばSSE2の利用など)に強く依存しており、JavaプログラムはJITコンパイルにより対象のアーキテクチャに適応できることを示している。
エスケープ解析の手法は、オブジェクトがどこで使用されるかをコンパイラが知ることができないため、たとえばC++では使用できない(また、ポインタの使用が原因でもある)。
しかし、JavaとC/C++でのベンチマークによる比較は実施する作業に大きく依存する。例えば、Java 5.0と比較すると、
32 / 64ビットの数値演算、ファイル入出力、例外処理 ではC/C++と同等の性能を示す。
コレクション、オブジェクトの生成、解放、メソッド呼び出しの性能 では、Javaの方がC++より性能が高い。
配列 の操作はC/C++の方が高速である。
三角関数 の性能はC/C++の方が高い。
Javaアプリケーションの起動時は、膨大な数のクラス(プラットフォームのクラスライブラリの全てのクラスを含む)を使用前にロードしなければならないため、CやC++よりもかなり時間がかかることが多い。
起動時間の大半はJVMの初期化やクラスのロードそのものではなく、I/Oを伴う操作によるものと思われる (rt.jarのクラスデータファイルは40MBあり、JVMは多数のデータをこの巨大なファイルをシークして取り出さなければならない)。いくつかの実験により、バイトコード検証分割の方法を用いるとクラスのロードは約40%向上するが、大規模なプログラムの起動時間は5%しか向上しないことがわかった。
改善幅は小さいものの、単純な操作を実行しすぐ終了するような小さなプログラムでは、Javaプラットフォームのデータローディングはプログラムの操作の数倍の負荷であるため、向上が目に見えやすい。
Java SE 6 Update 10より、オラクルのJREにはQuick Starterが同梱されるようになり、OSの起動時にクラスのデータをロードしておくことで、ディスクではなくディスクキャッシュからデータを読み出すことができるようになる。
Excelsior JETでは、この問題に対して別の方向からアプローチしている。JETのStartup Optimizerはアプリケーションの起動時にディスクから読み出すデータを削減し、さらにシーケンシャルに読み出せるよう配置する。
Javaの性能(ジャバのせいのう)では、Javaプラットフォームの性能について説明する。プログラミング言語としてのJavaに対する批判や、Javaプラットフォームの性能に対する批判は「Javaに対する批判」の記事を参照のこと。この記事ではJavaプラットフォームの性能について批判以外の説明をする。
プログラミング言語Javaは、その「ネットワークから送り込まれるプログラムの安全な実行」や「write once, run anywhere」というスローガンを、業界にありがちなスローガンだけのスローガンではなく可能な限り達成するべく、Javaバイトコードにコンパイルするコンパイラと、Javaバイトコードを解釈実行するインタプリタであるJava仮想マシン (Java VM, JVM)、という構成の実装を、公式の実装として伴って発表された。
コンピュータ科学的には特に目新しいものではない。