Javaの最適化

第1章. 最適化とパフォーマンスの定義

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

。パフォーマンス分析には神秘的な雰囲気がある。一般的には、「拷問を受けながら深く考える孤独なハッカー」（コンピュータとそれを演算する子に関するハリウッドのお気に入りの題材の1つ）が実践する技術として捉えられている。そのイメージは、システムを深く洞察し、システムをより速く動作させる魔法の解決策を考え出すことができる1人の個人というものだ。

このようなイメージは、パフォーマンスがソフトウェア・チームの二の次であるという不幸な（しかし、あまりにも一般的な）状況と結合することが多い。 このため、分析が行われるのはシステムがすでにトラブルに陥っているときだけで、それを救うためにパフォーマンスの「ヒーロー」が必要になるというシナリオが設定される。 しかし、現実は少し異なる。

実は、パフォーマンス分析とは、ハードな経験主義とぐにゃぐにゃした人間心理の奇妙なブレンドなのである。 重要なのは、可観測性メトリックの絶対数と、エンドユーザや利害関係者がそれについてどう感じるかということである。 この明白なパラドックスの解決が、本書の残りの主題である。

Javaのパフォーマンス-間違った方法

何年もの間、Googleで "Java performance tuning "でヒットするトップ3のうちの1つは1997-8年の記事で、Googleの歴史のごく初期にインデックスに取り込まれたものであった。このページが上位に留まっていたのは、初期化されたランキングが積極的にトラフィックを誘導し、フィードバックループを作成していたからだと思われる。

このページには、完全に時代遅れで、もはや真実ではなく、多くの場合アプリケーションにとって有害なアドバイスが掲載されていた。 しかし、検索エンジンの検索結果で有利な位置にあったため、多くの開発者がひどいアドバイスにさらされることになった。

例えば、Javaのごく初期のバージョンは、メソッド・ディスパッチのパフォーマンスがひどかった。 その回避策として、一部のJava開発者は、小さなメソッドを書くのを避け、代わりにモノリシック・メソッドを書くことを提唱した。 もちろん、時が経つにつれて、仮想ディスパッチのパフォーマンスは大幅に改善された。それだけでなく、最新のJava仮想マシン（JVM）と、特に自動マネージド・インライニングによって、仮想ディスパッチは現在では呼び出し先の大半で排除されている。「すべてを1つのメソッドにまとめる」というアドバイスに従っていたコードは、最新のジャストインタイム（JIT）コンパイラーに非常に不利なため、現在ではかなり欠点がある。

不適切なアドバイスを受けたアプリケーションのパフォーマンスにどれだけの損害が出たかは知る由もないが、このケースは、パフォーマンスに対して定量的で検証可能なアプローチを用いないことの危険性を端的に示している。また、インターネットで読んだことをすべて鵜呑みにしてはいけない理由の、もうひとつの好例でもある。

注

Javaコードの実行速度は非常にダイナミックで、基盤となるJava仮想マシンに基本的に依存する。 古いJavaコードは、Javaソース・コードを再コンパイルしなくても、より新しいJVM上でより速く実行されるかもしれない。

ご想像の通り、このような理由から（そして後述するその他の理由からも）、本書はあなたのコードに適用するパフォーマンスに関するヒントを集めた料理本ではない。その代わりに、優れたパフォーマンス・エンジニアリングを生み出すための様々な側面に焦点を当てている： ...