パフォーマンスということになると、現在Ruby 1.9.1およびJRubyは、Ruby実装のパックを先導している。しかしながら、さまざまな理由でこれらRuby実装のいずれかへの遷移は、未だ可能 ではない場合がある。ある分野において、Ruby 1.9.xが1.8.7との互換性がなく、Rubyにネイティブ拡張を使用するRuby libsが欠如しているような理由がある。それを念頭に置くと、MRI 1.8.xは近い将来定着するようである。そこでそのパフォーマンスを向上させることに関心が集まる。
Brent Roman氏は、Ruby 1.8.x MRIに対するパフォーマンスの改善を実現した。Rubyのメモリリークを特に継続的に修正することから開始した(リンク)。
基本的な技法は、Kurt Stephens氏が提案したものの改良版である。それは、この1つのライナーのリークを取り除くだけでなく、
loop {@x=callcc{|c|c}}
マルチスレッドのロボット工学アプリケーションのリークも取り除く。Rubyプロセスは、かつては1日で結局20MB以上にまでなった。同様の実行は、今では10MB未満である。
結局のところ、リークは、Rubyの保守的なGCと上手く対話しないGCC最適化が原因である(リンク)。
ガベッジコレクターのメモリのリークは、まったくそれ自体の過失ではない。「C」マシンスタックが、オブジェクト参照で溢れていることが問題である。この 主な理由は、GCCコンパイラが非常に大きなスタックフレームを作成し、そこにある多くの値を初期化しないことである。Rubyインタープリターコア再帰 的表現evaluatorで使用される特定の「C」構造体は、特に大きく、まばらなスタックフレームを生成する。関数rb_eval()は、自分自身で数 百回も呼び出すかもしれない関数の起動ごとに、キロバイトサイズのスタックフレームを作成する。これにより、数百キロバイトのスタックになり、たいてい決 してなくなることのない古いオブジェクト参照でいっぱいである。
Brent氏はこれらの問題を修正することを目指しているRuby 1.8.7-patlevel72(リンク)に対し、パッチを提供した。
テスターは、現実世界のRailsアプリケーションを実行する一方で、パッチでの大幅なスピードアップを報告している(リンク)。また問題もいくつか報告された。そこで今後の行方を見守ることにする。
これらのパッチは、MRIを改善しているオープンソース(Ruby)コミュニティの別の例である。Mod_rails (またはREE)(参考記事)は、別の例である。MRIのガベージコレクターをフォークに優しくする(詳しくは、リンクされたニュース項目を参照)。
MRIのパフォーマンスは、コンパイルの様子により大きく変化する(参考記事)。
2009年はRuby 1.8.xに固執する計画か?もしそうなら、その主な理由は何か?
原文はこちらです：http://www.infoq.com/news/2009/01/ruby-patches-fix-leaks