Re: Ruby1.9で遅くなる項目

Ruby1.9での新VMの作者さんからコメントいただきました。わざわざありがとうございます。

たとえば，スレッドはネイティブスレッド化が問題になり，count_words は m17n の影響になります．

count_wordsが8倍以上遅くなるのは謎でしたが、m17nが原因ですか。しかしそうなると、他の文字列処理にも影響を与えるはずです。m17nが原因としてもここまで遅くなるとは思えないし、他のベンチマークは速くなっていてcount_wordsだけ8倍以上遅いというのもやはり解せないというのが正直なところです。

eval に関しては，よくぞ 3 倍で留めたな，という感覚です．ただ，erb は遅くなっていないため（ベンチマークがあります），その辺は問題ないかなぁ，という気もしています．

なるほど。erbではevalが遅くなる代わりに他の処理が速くなっているおかげで、結果として相殺されているんでしょう。そのため、ベンチマークは遅くなっていないかわりに大して速くもなっていない。

ちなみにevalが遅くなる理由って、結局なんなのでしょうか。byte code変換の分だけ1.8より遅くなるのは分かりますが、それだけで3倍の時間がかかるとは思えない。

例外処理については，「例外が発生すると遅い」です．コードを見るとわかると思いますが，例外を連発するベンチマークです．
逆に，例外が発生しないものについてはとても速くなっています．それを確認するベンチマークもあるので，ご参照ください．

これはいい戦略ですね。例外が発生する場合よりしない場合のほうがずっと多いですから、発生しない場合が高速化されるなら、発生する場合が2割程度遅くなるのは十分許容できるでしょう。

なんかCPUの投機実行を思い出しました。

IO まわりは native thread の絡みですね．ただ，この辺はまだまだチューニングできると考えています．

チューニングで速くなればいいんですが。

最近「エンタープライズRuby」というのを聞きますが、もしRubyが本当にエンタープライズを目指すのであれば、I/Oが遅いというのは良くないです（理由がなんであれ）。Native threadが原因ということがわかっているなら、native threadを使わないという選択肢も用意すべきではないでしょうか。

例えばApacheはコンパイル時にthread modelを切り替えられます。それとはちょっと違いますがJavaはJVMの起動時に-clientまたは-serverを指定することで実行モードを切り替えられます。同様に、Rubyでもコンパイル時または起動時にthread modelや正規表現エンジンを指定できる機能があると理想的です。

ただそこまで用意できるほどの開発リソースがRubyチームにあるかどうかわかりませんので、あくまで無責任な外野の一意見としてください。