asakusa.rb で話題に出たらしいので使ってみた。gem にあるらしいのでインストールして、READMEに書いてある通りに仕掛ける。
試しに http://github.com/hsbt/tdiary/tree/master/core/ の TDiary::Dispatcher::IndexMain をプロファイルしてみた。先頭の10個はこんな感じ。
%self total self wait child calls name 34.85 0.01 0.01 0.00 0.00 58 Kernel#instance_eval 5.88 0.00 0.00 0.00 0.00 11 Kernel#gem_original_require 4.13 0.01 0.00 0.00 0.01 22 Array#each 3.81 0.01 0.00 0.00 0.00 2 Kernel#eval 3.10 0.00 0.00 0.00 0.00 16 IO#read 1.78 0.00 0.00 0.00 0.00 19 File#initialize 1.59 0.00 0.00 0.00 0.00 17 IO#close 1.59 0.00 0.00 0.00 0.00 248 Kernel#singleton_method_added 1.32 0.00 0.00 0.00 0.00 3 <Class::Dir>#glob 1.22 0.00 0.00 0.00 0.00 3 Kernel#eval(d1)
まあ、予想通りとなんというか。Rackに載せ替えて最初の起動時のみ設定ファイルの読み込みをするようにすると夢が広がるかもしれませんね。
tDiaryをherokuで動かすなど - capsctrldays(2010-05-26)経由。
これはもっと評価されるべき!
kakutani さんが testable_tdiary で作った tDiary を Rack の上で動かす Rack::TDiaryApp と kdmsnr さんが作った DataMapperIO の合わせ技で実現できたみたい。まさに ART(After Rails Technology) の結集という感じでとても良いですね。
後でちゃんと書くけど、自分は上の Rack::TDiaryApp と steak + capybara で受け入れる人が開発者自身という受け入れテストを追加しているので、これがもう少し機能をカバーできるようになってから中身に手を入れるつもり。RubyKaigi2010までには何とか steak で外堀を固めてから、Rack層に手を入れたいなー。
残念ながらそんなに夢は広がりません。最初の起動時のみに設定ファイルの読み込み(や、(tdiary.rbとかのロード)をするようにすると、今度はリクエストごとにpluginのコードをロードしているコストが高いことに気づくと思います。<br>なお、第二tDiary.Netでは、1ユーザごとに1常駐プロセスをあげずに、一つのFCGIプロセスで複数のユーザを扱うために、設定ファイルの読み込みもリクエストごとにやっていますが、pluginのコードのロードの方がコストがずっと高いと思います。<br>pluginを、静的なものと動的なものに分けられたら、たぶん静的なものはロードしっぱなしにできると思うのですが、そこまでは試していません。
適切なコメントありがとうございます。<br>今朝もたださんとも軽く話していて、instance_eval は ERb じゃねーのって話になっていて、設定ファイルはあまり影響ないみたいですね。<br>うーん、使っている plugin の eval も減らす(か別の何か)も考えないとダメな時期なのかなあ。