「Matzから、Rubyパフォーマンスポイントを教えてもらおう」参加メモ
かなり前に参加したが、メモが見つかったので残しておく。
3年以上前だが、パフォーマンスチューニングの考え方は普遍的なもので非常に参考になる。
かなり昔なので、間違えていたらご容赦くださいmm
１.「Rubyのパフォーマンスはどこまで上げられるか。あるいはRubyは本当に遅いのか？」
登壇者：Matz（まつもとゆきひろ氏）
前提としてMatzのRailsアプリ開発経験は、ゼロ or 1
Rubyは本当に遅いのか？
遅いの定義
- turing完全
- ある一定以上の言語は任意のアルゴリズムを記述ができる
- 言語によってできることは本質的には変わらない
- そもそも遅いかどうかというのは、状況、環境、問題があってはじめて決められる
- だから、どんなに早くても遅いし、どんなに遅くても早い
パフォーマンスチューニングすべきなのか
- 感覚と勘ではダメで計測すべし
- 早すぎる最適化は諸悪の根源
- どの程度速い必要があるのか？
- どの程度コストをかけられるのか？
- 生産性があくまでも最重要
- 最重要なのは楽しくプログラミングすること
- モチベーションが上がり、パフォーマンスが向上し、生産性があがる
- ハードウェアがボトルネックになることは時代的にない
- 楽しく速く開発すべし
- 必要最低限だけ改善する
パフォーマンス・チューニング
パレットの法則
- 80:20
- 実行時間の8割は2割の部分で消費される
- 実行時間の5％占める部分を高速化しても無駄
- ボトルネックしか意味が無い
- 感と感覚ではだめ
測定
アルゴリズムを適切なものに変える
- その他の改善手段とはオーダーが変わる
- ビッグオー記法(ex. O(n2) )
- どのオーダーで動くのかを常に把握
自分で仕事しない
- Rubyのライブラリコードは最適化されていることが多い
- 工夫されたCコードで記述されている
- 自分で実装するよりも速い
オブジェクトアロケーションを避ける
新しいRubyを使う(2.2のお話)
- 遅いところはコスト度外視で改善するよう開発している
- 0.1ごとに5〜10％パフォーマンス上がる
- 金利より高い率
- GCの改善
- メモリアロケーションの改善
- メソッド呼び出しの改善
- 高い互換性
- Ruby2.1からの移行はトラブルは起きにくい
まとめ
- 高速化は目的でない
- 良いアルゴリズムの検討
- 自分で仕事しない
- gemとかをつかう
- オブジェクトアロケーションを避ける
- 新しいrubyを使う
- パフォーマスチューニングは楽しい
- けどすごい意味はない
- 目的は見失ってはいけない
- それでもやりたければCRubyコア開発へようこそ
- 基本的には、計測するして改善する必要ができるまではする必要がない
Q&A
注目している言語などは？
- クリスタル
- エリクサー
２.「自社サービス"ALL-IN"（Rubyアプリ）開発における処理速度向上Tips」
登壇者：竹中 翔 株式会社ビジネスバンクグループ CTO ALL-IN事業部
All-INのパフォーマンス・チューニング（単体テスト）
事業概要
開発では自動テストを重要視してる
- 13000コミット
- テストケース20000
- テストのスピードアップ
テスト周りのgem
- rspec
- resque_spec
- factory_girl
- database_cleaner
faker
外部リソースアクセスに時間が掛かる
- テストのセットアップ
- 不要なデータをDBを入れてない？
- 同じ様なものを毎回DBに入れてない？
- DBでなくインスタンスがあれば十分でない？
３.「Rubyをテーマにしたライトニングトーク」
メモが残っていなかった。。
