GoGaRuCo 2013 - Measuring Ruby by Sam Saffron and Jeff Atwood - YouTube
YouTube の Watch Later に入ってたのを消化した。硬派なパフォーマンスチューニングの話。以下視聴メモ。
- Discourse のパフォーマンスチューニング、特に Ruby プログラム部分の話
- 前半でクヌースの「早すぎる最適化は悪」を引用しつつ、サイトが遅い原因の大半はフロントエンドにあると指摘
- しかしフロントエンド最適化の話はせず（おそらくそれは踏まえた上でなおサーバーサイドを限界までチューンする話、だったのだろう）
- dtrace の扱いづらさ（？自信なし）を経て rbtrace に触れる
- rack_mini_profiler の使い方に触れる、 /?pp=help とすると裏コマンドがいろいろ見られる
- memory_profiler gem を使うとメモリについて詳しいことがわかる、オブジェクトが作られた数とかそれによって消費したバイト数とか（動画内では ruby-head が必要とあるけど一年前の動画だから。 2014 年現在はふつうに最新リリース版の 2.1 系で使える）
- あと flamegraph オプションを使うとコールスタックがカラフルなグラフで見れる
- それらを踏まえてオブジェクト生成コストを減らすコーディング指南とか、常に実行可能なベンチマークコードを持っておいてライブラリの新しいバージョンに対して実行し改善や悪化を計測可能にするとか
僕はこう思ったッス
- 動画のタイトル見たとき「まさかあの Jeff Atwood なわけないよなー、同姓同名の人なんだろうけど気の毒だなー」と思ったら本人でびっくりした
- 大規模ハイトラフィックサイトにおけるハイパフォーマンス Ruby プログラミングという感じでためになった
- 個人的にパフォーマンスへの関心が薄くてベンチマークの類いにもあんまり興味が無いのだけど、技術者としてやっていく上でそれはマイナスに働きそうだなという懸念が以前からあったので、たまにこういうのをみると刺激されてよかった
- とはいえ個人的には消費メモリを節約するためにオブジェクトの属性をハッシュに詰め直す、みたいなコーディングの工夫でがんばる方向性にはやっぱり賛成できなくて、だったらもっとメモリ効率の良い、用途に適した言語で書けばいいのに、と思ってしまう（もちろん習得コストとかいろいろあるけど、必要に迫られたらできるはず）
- とはいえ遅いと言うだけよりはコードとデータで示したほうがよっぽどいいし、そういう動きがないと処理系を作る側にも伝わらないだろうから、やっぱこういうことをする人はそれはそれで偉いと思った
- script/bench.rb で Rails edge とかに対して Discourse のベンチを走らせて継続的にパフォーマンスの変化をチェックする、というのはちゃんと人柱になっててえらいなーと思った。ノブレス・オブリージュっぽさを感じた
- flamegraph というものを初めて見たけど youpy さんっぽいなと思った
