「推測するな計測せよ」は「性能上がらなかったら捨てろ」ではない
「推測するな計測せよ」という格言がよく知られています。この格言は（ISUCONに優勝した）Goの作者の一人でもある、 Rob Pike 氏の言葉が元になっています。
UNIX哲学 on Wikipedia
ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。
ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。
このルールは、推測だけで高速化のための変更をすることを諌めていますが、直接に高速化の効果が無い変更をするなとは言っていません。
正しいデータ構造やアーキテクチャは、それだけでは性能が向上せず、それを利用した改善を入れて初めて効果があることがあります。 そして正しいデータ構造やアーキテクチャを選ぶには正しい理解が必要で、計測はそのために必要なものです。
もちろん、プロジェクトによっては、そのアーキテクチャ変更が将来的にどれくらい効果があるのかをだれかに納得させるために（あるいは自分で納得するために）検証目的の荒削りのものでいいからそのアーキテクチャ変更を利用した高速化を実装しないといけないかもしれません。
さて、今年のISUCONでは、オンメモリ化（プロセスメモリ上に整合性の取れたデータを残して参照クエリを撲滅する）がキーポイントの1つでした。 （ちなみにもう一つのキーポイントはデータの特性に合わせたキャッシュでした。）
ただし、今年のISUCONの課題では最初からCPUネックでした。単にオンメモリ化しただけではスコアはあがりません。初期実装はロック競合が激しいので、ロックのつまり具合でスコアが乱高下するので、計測してみたらスコアが下がった人も多かったでしょう。
でも、オンメモリ化は正しいアーキテクチャでした。ロックをDBから引き剥がす事ができるし、（一番効果があったJSONまるごとキャッシュには関係しないものの）多倍長整数の値を文字列との相互変換をせずに直接キャッシュすることもできました。
もし、オンメモリ化しても大して効果がないから変更しなかったというチームがあったとしたら、この格言が「理解せずに変更するな」であって「性能向上しない変更をするな」ではないことを覚えておいてください。
（ただし、もう一つのキーポイントであるキャッシュを攻略すれば、オンメモリ化してなくても優勝チームのスコアを超えることは難しくなかったと思います。キャッシュについてはまた別に記事を書きます。）
@methane
この記事にコメントする
| 名前: | |||
|---|---|---|---|
| メール: | |||
| URL: | |||
| 情報を記憶: | 評価: | 顔 星 | |
 |
|||