ActiveRecordを速くしたいだけの人生だった - Qiita

Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを

[sifue]

モンキーパッチて対応せざるを得ないことを考えると、Railsプロダクトもマイグレーションコストは安くないなぁと思う。

[kamm]

普通の使い方をして、普通のパフォーマンスを出すのにここまで苦労が必要になって言うのはフレームワークのあり方として問題じゃないの？

[tbpg]

“「推測するな、計測せよ」”

[yamaz]

Rails側での対応を待ってたら改善されなくて、足かけ1年がかりになっちゃいました。まじ乙！ @yuroyoro

[michael26]

rubyプログラミングにおける問題解決をどのような手順、手段でとりおこなっていくのかということがよく示されていて大変勉強になる。思考過程ってなかなか明文化されないからありがたい。

[rgfx]

(なんでそこまでしてORMを使うんだ…。

[reitanigawa]

railsは絶対エンタープライズ案件に向いてないとおもうけどなぁ。

[sudix]

すごいけど過去の経験的にRailsでバッチは書かないほうがいいと思う。長く使われそうなものなら尚更。でも作り始めるときは分からないんだよなぁ・・・。

[auient]

Railsが遅くなった原因と解決策を探る話。/ メジャーバージョンアップして遅くなるとは。rails 4になって嬉しいことと比較してどうなんだろう？

[todesking]

尊い

[inouetakuya]

つよい

[akatakun]

チューニングの際に参考になりそう，Railsで速度が重要なバッチ処理を実装するのはあまりおすすめできない

[igrep]

お疲れ様でした...

[yusk_y]

Ruby - ActiveRecordを速くしたいだけの人生だった - Qiita

[miguchi]

すごい

[uemasaharaki]

なんでそういうバッチをrailsでかくかな

[oakbow]

こりゃすげー。自分だったら遅いバッチ処理はAR使わず生SQLでやる方に逃げるけど、正面切って戦う必要があったってことだよね。ちゃんと勝利しててすごい。

[kazutox]

面白い

[honeybe]

大作。あとで。

[h5y1m141]

こういう処理をどうやって計測するか方法知らないところがたくさんあるので、これはいいまとめで、すごい助かる

[ikosin]

調査の過程がすごい有用な資料 / 茨のレールだ

[UDONCHAN]

有用情報

[warufuzaketaichi]

バッチ処理はレールの外か…

[fjwr38]

めちゃめちゃ大変そう

[uraxurax]

（ソース：https://twitter.com/mizchi/status/588001943844335616） iPadから送信

[Jxck]

ruby-prof, stackprof, benchmark-ips, kcachegrind etc

[send]

つらい

[t-wada]

yuroyoro 先生の大作。「推測するな、計測せよ」という姿勢の大切さもよくわかる。

[nakaearth]

おお、そうなのか、なるほど。

[nkazuki]

ぜひ英語でも書いて欲しい記事

[takadayuichi]

あとで読む

[rochefort]

これはつらい

[joker1007]

流石の仕事っぷりだなあ……。やっぱ計測大事だ。stackprofの活用事例としてとても参考になる。