A Philosophy of Software Designの20章要約

本内容は「A Philosophy of Software Design」の20章を要約する記事です。

過去記事

20章の要約

20章パフォーマンスのためのデザイン
概要
- きれいな設計を犠牲にすることなく、高いパフォーマンスを達成する方法について説明する
- シンプルであることはシステムの設計を向上させるだけでなく、システムをより高速にする
パフォーマンスをどう考えるか
- 通常の開発プロセスにおいて、パフォーマンスをどの程度気にすべきか
  - すべてのステートメントを最適化して速度を上げようとすると、開発のスピードが落ちるし、不必要に複雑になる
  - パフォーマンスの問題を完全に無視した場合、コード全体に多数の非効率な部分が存在することになり、その結果、システムは必要な速度の5倍から10倍も遅くなる可能性がある
- 最適なアプローチは、この両極端の間にあるもので、パフォーマンスに関する基本的な知識を使って、「自然に効率的」かつ「クリーンでシンプル」な設計案を選択すること
- どの操作が基本的にコストが高いか
  - ネットワーク通信は10~50μsから10〜100ms
  - ディスクI/Oは5〜10ms、SSDは10〜100μs、メモリは1μs
  - キャッシュミスはパフォーマンスに影響する
- コストを知るにはマイクロベンチマークを実行する
- 多くのケースで、より効率的なアプローチはより遅いアプローチと同じように単純である
  - 大きなオブジェクトのコレクションを保存し、それをキーとして検索する場合、ハッシュテーブルや順序付きマップを使用することができるが、ハッシュテーブルの方が高速である
- 一般に、複雑なコードよりも単純なコードの方が高速に動作する傾向がある
  - 特殊なケースや例外を排除して定義すれば、それらのケースをチェックするためのコードが不要になり、システムの実行速度が上がる
  - 深いクラスは浅いクラスよりも効率的、各メソッド呼び出しに対してより多くの作業が行われるため
修正する前に測定する
- 直感に基づいて変更を始めると、実際にはパフォーマンスを改善しないことに時間を浪費することになる。そして、複雑にする
- 変更を加える前に、システムの既存の挙動を測定する
  - パフォーマンスのチューニングが最も大きな影響を与える場所を特定する。システムの改善ポイントをごく少数、具体的に特定する
  - 基準値を設定する。これにより、変更後にパフォーマンスを再測定し、実際にパフォーマンスが向上したことを確認する
- パフォーマンスが向上しなければ、複雑にしておく理由はない
クリティカルパス周辺の設計
- 既存のコードをより速く実行できるように設計し直す方法について
- 最も一般的なケースで実行しなければならない最小量のコードであるクリティカルパスのみを実装した新しいメソッドを書いていると想像する
- 理想的なコードは、おそらく既存のクラス構造と衝突し、実用的でないかもしれないが、良い目標を提供する
- これはコードがこれまでで最もシンプルで高速であることを表す
- 次に、きれいな構造を維持しながら、理想にできるだけ近い新しい設計を探す
- 理想的なコードを（ほとんど）そのまま維持するという制約のもと再設計する
- このプロセスで最も重要なことの1つは、クリティカル・パスから特殊なケースを取り除くこと
- コードが遅いのは、さまざまな状況を処理しなければならないためで、コードはすべての異なるケースの処理を単純化するように構成する
- 各特殊なケースは、余分な条件文やメソッド呼び出しの形で、クリティカルパスに少しづつコードを追加し、コードを遅くする
- パフォーマンスのために再設計する場合は、チェックしなければならない特別なケースの数を最小限にする
- 理想的には、冒頭に1つのif文があり、1回のテストですべての特殊なケースを検出する
- 特殊なケースでは性能はそれほど重要ではないので、性能よりも単純さを重視して特殊なケースのコードを構成することができる
結論
- クリーンな設計と高いパフォーマンスは両立する
- パフォーマンスにとって最も重要なクリティカルパスを見つけ、それを可能な限りシンプルにする