Rubyのパフォーマンスはどこまで上げられるか。あるいはRubyは本当に遅いのか？

Powered by Rabbit 2.1.8
Rubyのパフォーマンスは
どこまで上げられるか。
あるいはRubyは
本当に遅いのか？
Rubyアソシエーション理事長
ネットワーク応用通信研究所
Heroku
まつもとゆきひろ
@yukihiro_matz
Yukihiro "Matz" Matsumoto

　
Railsアプリ開発経験

　
ゼロ (or 1)

　
Rubyは本当に遅いのか

　
「遅い」を定義せよ

　
エンジニアは感覚と勘で
仕事してはいけない

　
Premature optimization is the
root of all evil
Donald Knuth

　
早すぎる最適化は諸悪の根源
ドナルド・クヌース

　
どの程度速い必要があるか

　
どの程度コストをかけられるか

　
生産性が重要

　
最重要は「たのしいプログラミング」

　
パフォーマンス最重要は昔の話

　
たのしく(速く)開発して

　
必要最低限速くする

　
パフォーマンスチューニングの鉄則

　
パレートの法則

　
８０：２０則

　
実行時間の８割は
２割の部分で消費される

　
実行時間の５％占める部分を
超高速化しても全体は
９５％にしかならない

　
ボトルネックしか意味がない

　
パフォーマンスチューニングの鉄則２

　
測定

　
数値

　
遅くなる様々な要素

　
処理系の遅さ(Rubyの遅さ)

　
アルゴリズムの遅さ

　
データベースの遅さ

　
メモリの遅さ

　
GCの遅さ

　
原因が明らかなら解決は
(比較的)簡単

　
パフォーマンスチューニングの鉄則３

　
まずアルゴリズムを検討

　
その他の改善手段とは
桁(オーダー)が違う

　
O(ビッグ・オー)記法

　
O(n^2)

　
O(n・log(n))

　
O(1)

　
パフォーマンスチューニングの鉄則４

　
自分で仕事しない

　
ライブラリルーチンに任せる

　
Rubyのライブラリコードは
最適化されてる(ことが多い)

　
Cで実装されているものも多い

　
自分でCで実装するよりも
工夫されてる(≒高速)

　
パフォーマンスチューニングの鉄則５

　
オブジェクトアロケーションを避ける

　
メモリ問題

　
GC問題

　
文字列リテラル

　
部分文字列

　
コピーを避ける

　
例：長い文字列

　
正規表現＋インデックス
vs
部分文字列

　
ボトルネックに限定する

　
パフォーマンスチューニングの鉄則６

　
新しいRubyを使う

　
2.2

　
2.3

　
0.1ごとに５〜１０％改善

　
金利より高い率

　
GCの改善

　
メモリアロケーションの改善

　
メソッド呼び出しの改善

　
高い互換性

　
まとめ

　
高速化は目的じゃない

　
まず測定する

　
ボトルネックを見つける

　
より良いアルゴリズムを検討

　
パフォーマンスチューニングは楽しい

　
目的を見失う

　
CRubyコア開発へようこそ

　
ありがとうございました1

Rubyのパフォーマンスはどこまで上げられるか。あるいはRubyは本当に遅いのか？

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)