Javaの標準Collectionフレームワーク代替としてのfastutil/HPPCの使用のすすめ
Goな人が最適化しているエントリ(http://blog.golang.org/2011/06/profiling-go-programs.html
)を読んで、ちょっと面白いなと思ったので、元の論文を読んでみました。読んでみたところ、Java 64bit版は標準のC++の5.8倍遅いとなっていたので本当かな？と思い、元のプログラムを見てみました。
http://research.google.com/pubs/pub37122.html
プログラムをざっと見て、オリジナルのJavaの標準のコレクションフレームワークの使用時の罠にはまっていることに気づいたので、以下のチューニングを施してみました。
- -XX:+UseCompressedOopsオプションを使っても、Integerなどのオブジェクトはプリミティブ型の数倍のメモリ消費量を使ってしまうことから、整数オブジェクトの配列ではなく、プリミティブ型専用のコレクションを使うこと
- 内部のストレージにダイレクトにアクセスが可能なオーバーヘッドの少ないコレクションを使うこと
- Iteratorでのアクセスが遅いことから、拡張for文を使うのではなくリストにダイレクトにアクセスすること
たった数十行の修正で、C++のバージョンよりも約2割ほど早くすることができました。また、このコードは、オリジナルのmulti-language-benchmarkプロジェクトのJavaでの最適化バージョン(java-pro)のものよりも1割程度高速です。測定環境(CPU, Memory, Javaのversionなどなど）により性能値は変わるので、測定可能なコードを以下においておきました。
https://github.com/dann/java-multi-language-benchmark
ここで使ったのはfastutilなんですが、fastutil/HPPCは、Javaのコレクションフレームワークに近い（一部互換の）APIを持つ、上記のことを実現するのに適したコレクションフレームワークで、比較的簡単に標準コレクションフレームワークを使ったコードの置き換えが可能です。上記のような理由で、Javaのコレクションフレームワーク使用時に性能が出せない場合にはとてもお勧めできます。
また、Javaで性能を出すためのプログラムをどのように書けばよいのかという点で、とても学ぶことの多いソースであるので、アプリケーションとしてのJavaのコードを読み飽きた方にも非常におすすめです。何故Javaのコレクションフレームワークが遅いのかをJDKのコード、メモリの使用量などを調べながら読み比べてみると面白いです。
# YourKitでプロファイルした感じだと、もう少しチューニングできそうなので、暇な時にもう少しやってみようかと思ってます。
