BT

Rubyパフォーマンス概要:Ruby 1.9.1の実効性能、GC vs EventMachine、Rubyコンパイラについて

| 作者: Werner Schuster フォローする 9 人のフォロワー , 翻訳者 勇 大地 フォローする 1 人のフォロワー 投稿日 2009年5月31日. 推定読書時間: 2 分 |

原文(投稿日:2009/5/12)へのリンク

Ruby 1.9.1を使用する際に議論する対象の一つとして、著しく改善されたパフォーマンスが挙げられる。Ruby 1.8.x、JRuby、Ruby 1.9.1それぞれについて、実環境で行われた新しいベンチマーク結果が存在する

Acunoteを移植 -JRuby/Ruby1.9のプラットフォームで利用可能な、オンラインのエンタープライズ向けプロジェクト管理とスクラムソフトウェアであり、性能ベンチマークを実施した。

JRubyのパフォーマンス改善に用いるコマンドラインオプションについての議論は有るが、Ruby 1.9.1(1.9.1はJRubyよりも有利である)とJRubyの両方とも Ruby 1.8.6 より大幅に性能改善されている。

Ruby 1.9.1のパフォーマンス改善は、新しい機能の一部だけでなく高速なVMの上に成り立っている。Muhammed AliはRuby 1.9.1のFibersを用いたWEBアプリケーションのスケール方法を示した。しかし一方で、MuhammedはRuby 1.9.1のObject#extendに伴うメモリリーク問題について指摘している。

一方で、Ruby 1.9.1上では一部ライブラリが不足している為、Ruby 1.8.6は幾つかのプロジェクトに対しては唯一の選択肢となっている。これにより、Ruby 1.8.6のボトルネックを改善する事に多くの関心が寄せられている。Joe Damato はこれらの問題についてブログ上で調査していた。一例として、彼は--enable-pthread オプションの実態と、この設定を無効化した場合に30%も性能が向上する原因について調査している。別の記事では、Joe とAman GuptaRubyのGCに伴う問題について調査し、GCとEventMachineについての問題を修正する小さなパッチを考案している。

* スタックフレームサイズの大幅な削減により、GCの速度を2~3倍にした。
* Epollを使用するスレッドが原因となる、EventMachineが大幅に速度低下するオープンなバグを修正した。この原因は、各スレッドが全てのコンテキストスイッチ毎に800,000バイトのスタックを継承してコピーする為である。
* Sinatra+Thin+Epoll+Threadsを利用した場合、500 requests/sec から 7000 requests/sec に性能改善される。これはいかした改善だ。

最後に、Viktor Hokstadはずいぶん前からコンパイル式Rubyについてのシリーズを書いている。最近のエントリーはRubyを速く、できるだけ最適化する場合の問題点について述べている。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT