ruby-profが落ちるのはRubyProf.stopのところだけGCを止めたらうまくいった。
それはいいんだが見方がやっぱりさっぱりわからん。
なんか実行時間360とか出てるんだけどこれ何よ。あ、デフォルトではclock関数の値を使うから単位はCLOCKS_PER_SECなのか。Intel Macでは分解能100。え、1/100秒単位？めちゃくちゃ適当じゃないですか。
計測単位をCPUカウンタにしてみたらでかい値になってくれた。あと実行もとても速くなった。よしよし…ってええっ！なんでclock関数でカウンタ取るのとCPUカウンタ取るので見た目に明らかな差が出る程速度が違うんだ？
MacOSXのclockのやろー中で寝てやがるのかな…。
で、結構精度良く取れたはいいんだけどやっぱりわかんないなぁ。どうもループしちゃうのはそれはそれでいいみたいなんだけど、ずっと辿っていっても90%以上の実行時間がどこかにいっちゃってるんだよね。どこいったー。
ああ、ruby-profのCPUカウンタって当然CPUのカウンタ使ってんのか。マルチコアでやばくね？とおもったらやはりやばいらしい。特定のコアだけで動くように設定しないとダメだよね。それなおして確認するか。大きくはかわらないだろうけど。
昨日はMacのInstrumentsには標準でRuby対応無いとか書いたけど、全然そんなこと無かった。
確かにライブラリには入ってないんだけど、新しいインストラクションを作るとRubyのカウンタ取れまくる。
dtraceのスクリプト書かなくても簡単に設定作れるってだけだけど、dtraceのスクリプトわけわかんねーし書きづらいからとても便利だよ！
と思ったんだけど、細かい動作指定するなら結局書かないといけないのか。
しかしほとんど何も書かなくてもバックトレースとか関数の実行時間の割合とかは勝手に表示された！すげー！
Obj-Cレベルでだけどな！！！
Rubyでくれ。
あと下手するとすぐ固まる。めっちゃ重い。メモリがやばい程くったりする。うーん、dtraceってすごいけどめちゃくちゃ使いづらくね？
やっぱりruby-profでいいわ。