Javaパフォーマンス

2章

ベンチマーク

マイクロベンチマーク

Javaのコードはコンパイルするたびに早くなるらしい

なので、このウォームアップを行ってから計測に入るのが良さそう

特定の処理自体の速度のベンチマークっぽい

マクロベンチマーク

ユーザ視点での速度のベンチマーク

外部リソースを使った場合など、アプリケーションに対するベンチマーク

最適化が行われるため

ウォームアップ

正しいテストを行うためにコードのウォームアップを行う

JITコンパイラで最適化される

ウォームアップなしだと遅いので、ウォームアップによって最適化されたあとに計測するのが通例

ウォームアップを行うメリット

コンパイラによる最適化

キャッシュの有効利用

同じファイルをキャッシュして、ループなどを高速化f

3章

オペレーティング・システム付属のツール

CPUの使用率について

使用率とはどのくらい効率的にCPUが処理できたかの指標

CPU使用率50%でバッチ処理が1秒かかっているとすると、
使用率を100%にあげたら0.5秒で処理が完了する。

100%に使用率は上昇するが、そのほうが効率的なので望ましい

しかし、これは一定間隔でリクエストが来た場合や、他に処理するものがない場合などでしか意味はない。

CPUが単一と複数、スレッドが複数の場合でも目指すゴールは2つ

スレッド同士がブロックされないようにCPU使用率を上げること

多くのリクエストをさばけるようにCPU使用率を下げること

vmstatとか

ディスクの使用率

iostat

ファイル入出力がないアプリケーションもディスク監視はすべき

理由はメモリのスワッピングが発生する可能性があるため
Javaだとヒープのおかげで、顕著にメモリに影響がでるらしい。Javaアプリはメモリをいっぱいつかうから

スワップインやスワップアウト

一秒間の書き込み量

使用率

ネットワークの使用率

netstat

nicstat

JITコンパイラ

役割

プログラムからコンパイルによって中間コード(classファイル)になるが、それを機械語にコンパイルするもの

JITコンパイルされた機械語がCPU上に乗っかり処理が実行される。
JITコンパイルされるタイミングは特定のメソッドをコールしたとき。

複数回メソッドをコールするとJITコンパイラはキャッシュぽいことをして、同じコンパイルはしないようにする

コンパイル時に何度も実行されるようなコードはコンパイルを行っておくことで高速化できる

逆にそんなに使われないコードの場合はコンパイルしてもその時間が無駄なので、インタプリタっぽく呼ぶことになる

なにか?

JVM上に実装されているコンパイラ

クラスファイルを機械語にコンパイルして実行可能状態にするやつ

必要なものを必要なときだけコンパイルする

Javaのコンパイルから実行までの流れ

1. javaファイル
2. javacでコンパイルしてclassファイル作成
3. JVM上で実行
4. JVMのjavaインタプリタで実行
5. コンパイルした方がパフォーマンスが出そうならJITコンパイラによるコンパイルが実施される

あまり使われないコードをJITコンパイルしたとしても、その時間が持った無い

逆にequalsとかの場合は何度もインタプリタによる実行のほうがコストがかかる

なので、JITコンパイルして、機械語にしておいてやる
最適化だね

classファイルは中間コードであり、これを作ることでどのJVM上でも実行が可能

JVMのインストールはOS似合ったものにしておくとOK

JITコンパイラ種類

クライアントコンパイラ

サーバコンパイラ

階層的コンパイラ

早期にコンパイルを実施する
初期のほうが早くなる

様子を見て最適なコンパイルを行う
最初は遅いが、最適化がクライアントに比べ良い

早期にコンパイルして、より多く利用されるものについては、サーバコンパイラっぽく最適化を目指して再度コンパイルされる

Java7から試験的に導入されて、java8からはデフォルトとなってるらしい

オプションについて

コンパイルさせる閾値を設定することもできる

例えばメソッドが10回コールされたらコンパイルするように設定など