あなたはプログラムがどこで時間を消費しているかを理解していない。ボトルネックは予想外のところにある。推測するな。どこにボトルネックがあるか証明されるまで高速化するな。 計測せよ。計測するまで高速化するな。計測して、コードの一部分が他の部分より圧倒的に時間を消費しているのでなければ、高速化をするな。 (Rob Pikeの文章の西尾による訳)
Rob Pike, who became one of the great masters of C, offers a slightly different angle in Notes on C Programming:
Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.
Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)
Rule 4. Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.
Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
Rule 6. There is no Rule 6.
訳注
- tellは「あなたは確信を持って言うことができない」と言うニュアンスだが、そう書くとまどろっこしいので「理解していない」とした
- speed hackとかtuneは「速度を向上させる目的でソースコードの小さな一部を書き換えること」というニュアンスだが、まどろっこしいので「高速化」とした。
- 単語だけの意味としては「データ構造や設計を工夫することで高速にすること」も含んでしまうが、ソースコードができた後でボトルネックを特定しないで高速化してるって話なので誤解はしないだろう
- and even thenは「まず計測しろ、計測するまで高速化するな、そしてたとえ計測した後であっても…」というニュアンスなのだが、日本語にするとand even thenの手前にあったmeasureが遠くに行ってしまう。そこで文を切って「計測する」を再掲することにした。
関連: Basics of the Unix Philosophy
表記揺れ