Ruby 1.8のGarbage Collectorは、過去多くの注目を集めた。Ruby Enterprise Edition (REE)のデベロッパは、GCに不正侵入し、プロセッサ全体でメモリを共有した(作成者とのInfoQのインタビュー(参考記事)に詳細掲載)。REEは、 Railsアプリケーションのデプロイおよび実行するための有名な方法となった。37Signalsやその他大勢がそれを使用している。近ごろ、REEの GCは改善された。散発的なフリーズを除去したバグ修正(参考記事)がある。スタンダードRuby 1.8.xのユーザは、多くのGC問題や関連したメモリリークを修正するMBARIパッチ(参考記事)からの改善をまもなく取得する。またEngineYardにより後援される。
Evan Weaver氏はGCチューニングチップ(リンク)を提供し、GCのモニターを許可するパッチを推奨している。提示されたチューニングの結果は、以下のとおりである。
GCは、13の要求ごとのみで実行する。わずかにコストが高く、0.009秒のリクエストごとのコストである。全体的には34%のスピードアップである。 GC呼び出しの周波数は、RUBY_GC_MALLOC_LIMITの変化と直接対応するが、それを増加すると、メモリ使用率は相当膨れ上がる。
よりパフォーマンスを取得するための別の方法は、現代のJVMのGCの成熟度から利を得るJRubyなど他のRuby実装を検討することである。他の実装は、最先端の改善を目指している。Rubiniusは着実に改善しており、近ごろMacRubyはパフォーマンスの改善を示したその実験的なブランチ(リンク)でニュースになった。実験的なブランチの作業は、進行している。
- コンパイラ(AFAIK)は、すべての言語スペックをコンパイルすることができるので、大体完成したのではないかと思う。
- 上記のおかげで、IRBは実行している。
さらなる改善(リンク)：
- Tail-call除去が導入された。スタックオーバーフローを避けるために、この最適化は、再帰的な呼び出しをローカルループに変換する。
- LLVM IRインタープリタはより高速な#eval表現の解釈のために、調査された。この調査の結果は、コミットされ、単純な表現とよく機能するが、VMプリミティブの呼び出しということになると、制限があるため、デフォルトで起動されない。MacRubyからそれを十分に札用するために、LLVMインタープリタを多少修正しなければならない。これは、近い将来実行される。
最後に、GemStoneのRuby実装、MagLevはプライベートAlphaテスト中であり、Q2でBetaが登場する。互換性(RubySpec)およびベンチマーク結果(リンク)は、MagLevのWebサイトで利用可能である。プロジェクトの更新は、Twitterでも利用可能(リンク)である。