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 GuptaがRubyのGCに伴う問題について調査し、GCとEventMachineについての問題を修正する小さなパッチを考案している。
* スタックフレームサイズの大幅な削減により、GCの速度を2～3倍にした。
* Epollを使用するスレッドが原因となる、EventMachineが大幅に速度低下するオープンなバグを修正した。この原因は、各スレッドが全てのコンテキストスイッチ毎に800,000バイトのスタックを継承してコピーする為である。
* Sinatra+Thin+Epoll+Threadsを利用した場合、500 requests/sec から 7000 requests/sec に性能改善される。これはいかした改善だ。
最後に、Viktor Hokstadはずいぶん前からコンパイル式Rubyについてのシリーズを書いている。最近のエントリーはRubyを速く、できるだけ最適化する場合の問題点について述べている。