あなたはコンパイラではない
パフォーマンス関連の議論でいつもイライラさせられるのは、解決策にフォーカスしている点です。「このトリックを使えばアプリが10倍速くなる」「メモリアロケーターをチューニングする方法」「可能な限り高速に配列へ追加する方法」などです。
こうした態度は、私の顧客やワークショップの参加者に時々見受けられます。そうした人たちは「今すぐRailsアプリを速くするための10のこと」を知りたがっているようです。
問題は、あなたのアプリケーションには何百個という異なるパフォーマンス問題があり得るという点です。Webアプリケーションは何十もの異なる技術レイヤーの上に構築されており、それぞれがパフォーマンス問題の原因となり得ます。1つの解決策(「JSの前にCSSをheadタグに入れる」)について話すことは、エンパイアステートビルの1つのレンガについて話すようなものです。そのレンガも確かに必要でしょう。しかし、レンガは他にもっとたくさんあるのです。
この後はこんな感じで続きます：色々な高速化手法についてたくさん学ぶことはある程度までは利益になるかもしれないが、色々な状況ごとに高速化のやり方は山ほどある。これを突き詰めていくと最適化コンパイラが多数の最適化手法を組み合わせて高速化を図るような進め方になってしまい、そういったやり方は計算機は得意だが人間はそうではない。我々はコンパイラではなく、科学者になるべきです。つまり、目の前にある問題について観察し、それが確かに問題であることを確認し、何が起きているのか仮説を立て、問題を再現し、解決方法を探すという流れを踏むべきです。
とあるRailsのウェブアプリでパフォーマンス・チューニングをやってみた日がありました。このとき自分は特に調べぬまま、たぶんN+1クエリがたくさんあるだろうからそれを潰しまくろうと思って作業を始めました。実際この改善は行えたのですが、他と比べてそこまで多くはアクセスされないページのN+1クエリを直しただけだったため、これ自体がサイト全体のパフォーマンスに大きく影響を与えるほどのものではありませんでした。DoSで叩かれまくってDBが詰まってサイト全体が遅くなる、みたいな可能性を潰したというメリットはあるのですけれども。 別の日、同僚が別の文脈で未解決のパフォーマンス問題に取り掛かっていました。そこでは実際にどこに時間がかかっているのか計測してみて、仮説と解決策をいくつか考え、そのうちのひとつを実行してみて実際にレスポンスタイムが改善するところまで行っていました。
これは良い流れですよね。やるべきことを最初から決め打ちせずに調査から入り、調べ上げて問題を見つけ、それが実際に大きな差を生んでいると確認する。そうすべきだと分かってはいるものの、自分はなかなか毎回は意識できていないな、と気付かされました。自分がパフォーマンス・チューニングをやったときは期間が短かったとはいえ、ちょっと決め打ちをしすぎていたな、と。「今すぐRailsアプリを速くするための10のこと」 で頭がいっぱいいっぱいになっていたようです。
もちろん、毎日書くコードにヤバい挙動を入れてしまわないように、「今すぐRailsアプリを速くするための10のこと」 をざっくりとは知っておくのは重要と思います。それはそれとして、今の状況を改善したいなら現状理解から始めるのが良いよねという話でした。