パフォーマンスの全体像

よりよいアルゴリズムを記述する

最終的にはパフォーマンスはコードの適切さにかかってくる。
特定の要素を探すコードだったら、いくらループするコードをなんとかしようとしても、HashMapを使うコードには勝てない。

コードの量を少なくする

いまだに書いたコード量で開発者を評価する管理者もいるが、
コード量が少ない場合のほうがパフォーマンス面で有利なことが多い。特にJavaだとこの傾向が強いらしい。

コンパイルしないといけないコードが増えれば、JITコンパイラのによってコードが速く実行できるようになるまでの時間が増加。
生成廃棄しないといけないオブジェクトの量が増えれば、GCの作業量も増える。
多くのオブジェクトを保持し続ければ、GCのサイクルが伸びる。
ロードするクラスが増えれば、起動する時間も増える。
実行されるコードのサイズが増えれば、キャッシュに収まらない可能性もある。

パフォーマンスは常に悪化する。機能追加がされていくため。

早まった安易な最適化

1日のうち97%くらいは、ささいな効率については忘れるべきです。早まった最適化は諸悪の根源です。

という有名な言葉がある。
クリーンで率直なコードを書いて読みやすくするようにすべきで、
分析をせずに最適化（パフォーマンス面で優位になる代わりに、構造が複雑になるような修正）するべきではない。
しかし、明らかにパフォーマンス面で問題になるようなコードを避けるというのは別の問題で、それはいいことである。

外部を見渡す(データベースは常にボトルネック)

外部リソースを使わないスタンドアロンの場合は、パフォーマンスでネックなのはそのアプリケーションだけ。
しかし、外部リソースを使う場合は、そこがネックになる。
本書では、Javaだけでなく、全体について分析がされていると仮定してJavaパフォーマンスについて説明を行う。

よくあるケースのために最適化する

頻度の高いユースケースに注力する。

Javaパフォーマンス 1章 イントロダクション