推測するな、計測せよ
Last Update: 2019.03.17 04:15:02
ルール1、2より。「早すぎる最適化は諸悪の根源である」の言い換えでもある。
-
ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。
-
ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。
-
ルール3: 凝った(Fancy)アルゴリズムは {\displaystyle n} nが小さいときには遅く、 {\displaystyle n} nはしばしば小さい。凝ったアルゴリズムは大きな定数を持っている[2]。 {\displaystyle n} nが頻繁に大きくなることがわかっていないなら、凝ってはいけない（ {\displaystyle n} nが大きくなるときでさえ、ルール2が最初に適用される）。
-
ルール4: 凝ったアルゴリズムはシンプルなそれよりバグを含みやすく、実装するのも難しい。シンプルなアルゴリズムとシンプルなデータ構造を使うべし。
-
ルール5: データはすべてを決定づける。もし、正しいデータ構造を選び、ものごとをうまく構成すれば、アルゴリズムはほとんどいつも自明のものになるだろう。プログラミングの中心は、アルゴリズムではなくデータ構造にある。
-
ルール6: ルール6は存在しない。