はじめに
「推測するな、計測せよ」って誰が言ったの？という話。
「推測するな、計測せよ」という言葉があり、いかにも、「憶測で物を言うな」という文脈での逃げワードとして使われがち。しかしいかにも日本語的に語呂が良すぎるので、日本語話者以外であるであろう誰かの意図を、日本語で良いカンジにリメイクしたものだと「推測」していた。
似たところに「マッカーサー元帥の部下であり、日本の産業界に統計学的手法をもたらし大きな影響を与えたというデミング博士」の
webサービスの性能改善や大企業に伝わるQC活動の文脈でよく使われる「計測なくして改善なし」*1、“if you can’t measure it, you can’t manage it.”
もある。でもこの記事によるとそれも誤用とのことでとにかく諸説あるようだ。じゃあ「推測するな、計測せよ」is何。推測していないで調べました。
「推測するな」の起源
元となったのはロバート・C・パイク氏の言葉として説明している資料が多い。本当は5か条。
ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。
ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。
ルール3: 凝った(Fancy)アルゴリズムは nが小さいときには遅く、 nはしばしば小さい。凝ったアルゴリズムは大きな定数を持っている。nが頻繁に大きくなることがわかっていないなら、凝ってはいけない（nが大きくなるときでさえ、ルール2が最初に適用される）。
ルール4: 凝ったアルゴリズムはシンプルなそれよりバグを含みやすく、実装するのも難しい。シンプルなアルゴリズムとシンプルなデータ構造を使うべし。
ルール5: データはすべてを決定づける。もし、正しいデータ構造を選び、ものごとをうまく構成すれば、アルゴリズムはほとんどいつも自明のものになるだろう。プログラミングの中心は、アルゴリズムではなくデータ構造にある。
ルール6: ルール6は存在しない。
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.[9]
Rule 6. There is no Rule 6.
というか6か条に見えるけれど、Rule 6 はサイトによりあったりなかったりする。「Rule 6. There is no Rule 6」の訳し方によるんだと思うのだが「ルール6はありえない（= この5つが絶対だ！）」ということ、なのでしょう。(以降説明の語尾に気をつけています。私の「推測」は推測とわかるように表現しています。)
「ルール1」と「ルール2」
2つから「推測するな、計測せよ」という言葉が生まれ、パフォーマンス最適化についての格言となっているらしい。Wikipedia記述だと、このルール1, 2は、ドナルド・クヌース 「早すぎる最適化は諸悪の根源」 を言い換えたものだという。
→参照
「推測するな、計測せよ」
=「どこがボトルネックなのかをはっきりさせよ」
=「早すぎる最適化は諸悪の根源」
あれ、何の話しているんだ？速度改善？
最適化は推測ではなく、実測に基づいて行うべし
きれいなコードとは、各部分の独立性が保たれることによって、理解しやすく修正しやすいコード。
で、最適化を行うと、きれいなコードを汚してしまう場合がある。
まずはきれいなコードを書き、その後必要に応じて最適化を行うべし。
最適化を行う場合は、どの部分を最適化すべきかを判断することが重要。
どの部分を最適化すべきかの判断を、推測に基づいて行うのは良くない。実測してから行うべし。
よって、「推測するな、計測せよ」とは
「20年以上プログラミングしてきた人しか知らないこととは？」に対するJohn Byrd氏の回答
あなた方は皆、メモリー、プロセッサー時間、ネットワークの帯域といったものはすべて無料で、無限にある前提でプログラミングを教わってきたでしょう。そんなことはありません。そんなことはありません。そんなことあるわけないんです。Knuthのpremature optimizationに関する段落(訳注 : Donald Knuthによる有名な格言「早すぎる最適化は諸悪の根源(premature optimization is the root of all evil)」が書かれた論文の該当する段落のこと)の残りの部分を読みましょう。
数ヶ月したら、自分が書いたコードが何をするものかも忘れてしまうでしょう。バカみたいに読みやすくしておきましょう。
ということを言いたい。バカみたいに読みやすくして、計測できてから、初めて速度の最適化に進めるのよ、ということ。何だ別に、「憶測で物を言うな」っていう話でもなさそうだなという、いかにもな寓話が勝手に一人歩いていたようなフレーズ、「推測するな、計測せよ」でした。
本文とは関係ない参考記事
以上お楽しみいただければさいわいです。