CでRails互換フレームワークを、という話ではなく、 本当にパフォーマンスが必要ならRubyInlineを使って、 Cコードを埋め込むことでパフォーマンス改善できるよ、という話。
このエントリの場合には2 reqs/secが21 reqs/secと10倍の改善が可能であったそうな。 もちろん、彼のアプリケーションがどのようなものであったのか分からないし、 おそらくはほとんどの場合にはRubyInlineまでは必要になることはないと思うのだけど、 もし本当に必要ならそういう手もあると知ってることは悪いことではないだろう。
なお、彼(Jared)は、この経験をもとにOSCONでUse C to Tune Your Rails Applicationというプレゼンを行うそうだ。
もうひとつ、Railsパフォーマンス改善テクニック。
Rails(というかActiveRecord)は、SQLを隠蔽しちゃうんで、 SQLのSELECT DISTINCTを実現するのに、たとえば
@distinctlist = Item.find(:all).map{ |i| i.fieldname }.uniq
なんてことをやっちゃうことがあるんだけど(あるの？ ありそう)、 実は、
Item.find(:all, :select => 'DISTINCT fieldname')
とやる方がずっと効率がいい。当たり前といえば当たり前だけど。 データベースのことはデータベースにやらせた方が(効率が)よい。
もっとも、それで生SQLばかり使うようになるのでは本末転倒だけど。
ならいっそActiveRecordなんて使わないでSQLをそのまま(でもRuby風に)使いたい、 というのがSequelである。
私はDBプログラミングの経験がないんで使い勝手とか想像してもよくわからないんだけど、 SQLの雰囲気がそのまま感じられるような気がする。 でも、せっかくだからfilterとかでなんでも文字列で渡すんじゃなくて もうちょっとメソッドに隠蔽(で、内部的にSQLを生成)するアプローチをとってくれた方が Ruby風味が高くて「おいしかった」かも。
PythonのSQLArchemyとかそんな感じなの？
Rubyでは31bitまでの整数は即値といってタグをつけてポインタ値に埋め込んでいる。 これはインタプリタ実装の基本的な最適化テクニックで、これによって 普段よく使う整数値の効率が非常に高くなっている。
一方、浮動小数点数はこのテクニックの対象外になるので、 小数ひとつひとつのためにオブジェクトが割り当てられ、 効率が非常に悪くなっている(大きな数Bignumも同様)。
で、リンク先はタグをつけて埋め込む技術を浮動小数点数に適用する方法について。
「値」が最低64ビットになってしまうというのは、ある意味デメリットであるが、 最近ではポインタ64ビットなアーキテクチャも増えてるし、 そろそろ現実的な選択肢になってきてるのかも。