ruby-dev

なひです。

> From: Yukihiro Matsumoto [mailto:matz@ruby-lang.org] 
> Sent: Monday, November 18, 2002 2:09 PM

> |1.7のほうのeval.cに、いくつかtraceイベント発生用の
> |コードを修正/変更したいです。複数の項目があります。
> |追加すべきものかどうかという議論に加え、実装が
> |正しいのかどうかの議論/チェックもお願いしたいです。
> |特に6、7が怪しい。^^;
> 
> 新しいイベントを増やすのはできるだけ避けたい。今の枠組みでは

実際にそう決まれば、デバガやカバレジツール側でいろいろ
こねくり回して頑張る踏ん切りがつきます。

の前に、いくつか確認させてください。

> 新しいイベントを増やすのはできるだけ避けたい。今の枠組みでは
> イベントが増えれば増えるほど(飛躍的に)遅くなりますから。むし

ここでの「イベント」は、イベントの種類、ではなく、
発生する延べイベント全ての意味ですよね?
この、「(飛躍的に)遅くなる」は、
1. trace_funcハンドラを設定している場合
2. trace_funcハンドラを設定していない場合
の、どちらでしょうか。

1であれば、どうせ現時点でもそれなりに遅いですよね。
実測で「飛躍的」に遅くならないことが確認できれば、
部分的に追加してもよかったりします?

2であれば、遅くなるのは確かだと思いますが、
if (trace_func)のチェックって、「飛躍的」というほど
遅くなるんでしょうか。って、こちらも実測してみればよいのか。
perl4みたいに(*)、-DDEBUGでコンパイルしたときのみ、
なんてのはアリ？

# そんなことしたら、デバガ、プロファイラユーザが減りそうだけど。^^;

(*) perl5がどうなってるのか知りません。さらにはperl6の予定も。

> ろ、イベントごとに独立したハンドラを設定できるようにしてから
> 増やすことを考えたいです。

こちらの「イベント」は、イベントの種類ごとに、という
意味ですよね。これができるようになると便利だと思います。

set_trace_func(trace_proc, event_array = nil)
  event_array: line, call, class, c-call, raise, condition,
               load-callのsymbolもしくは文字列の配列。nilは全部。

とかいう感じ？

今回追加を提案した"condition"、"load-call/return"を加えて、
使われ方を想定すると;

debug.rb:
  line, call/return, class/end, raise/rescue, condition,
  load-call/load-return

profile.rb:
  call/return, c-call/c-return

tracer.rb:
  *

プロファイラは劇的に早くなると思います。他はあまり影響を
受けなさそうですが、例えば今後、classとメソッド定義にだけ
hookを打って、呼び出し関係をグラフで表示するIDEなどは、
call/returnとclassのみトレースするだけで済むでしょう。

で、やっぱり、まずは作って見やがれ、ということなんですかね。^^;

Thread

Prev Next

In This Thread

Prev Next