[EMAIL PROTECTED] wrote:
Hi Joe,
I'm relieved (maybe relieved is the wrong word), to hear, that I'm not the
only one who is suffering from the slow debugger. I had a quick look into
eclipseDebug.rb some time ago and asked, if porting eclipseDebug to C could
be a solution. As noone has answered :-(, I ceased examining the debugger.
What I've found up to now:
- eclipseDebug.rb installs a traceProc (set_trace_func at the end of the
file)
- the traceProc is called for every event that occurs in the interpreter
(e.g. every line, c-call, c-return, ...). So this probably is the place that
eats up all the time. I guess the trace_func is evaluated in toplevel -
context, so the profiler shows it as #toplevel
- you can check, that the trace_proc causes the delay, if you comment out
the set_trace_func command at the end of eclipseDebug (but the debugger is
rather useless after this).
Maybe the original author of eclipseDebug.rb could give us a hint where to
start improving the debugger? Implementing the whole debugger as C-Code?
Implementing only the trace_proc in C? Or removing the trace_proc at all
(ruby seems to have build in debugging facilities)
When I started to write the debugger for RDT, I started with the
debug.rb from ruby version 1.6.8. This original code still makes up a
fair share of the current eclipseDebug.rb. I don't know who the author
of the original debug.rb is.
My first approach was to just extend the command line debugger
(debug.rb) with additional commands to deliver the information we need
for RDT and share this code with the ruby release. But then I found that
there were requirements which made this approach too cumbersome:
* the input read loop may not be in the main thread but must reside in
its own thread
* the data from the debugger must be readable from RDT and therefore the
format which pleases the users eye had to be replaced with a format
which is easily to parse: XML was chosen
Dirk, I think your assessment of the code is quite right: the traceProc
is the part which is called for every new line, function call and return
and therefore consumes the most time. This is the part where a C
implementation could have the best impact. As opposed to that the time
consumed in the input reader and command execution is not relevant. The
C traceProc could be run instead of the traceProc of the current ruby
implementation and pass control the ruby implementation only if a
breakpoint is hit or an exception occurred.
As far as I can tell a traceProc module written in C would at least need
the following interface:
* a breakpoint and catchpoint administration, there must be functions to
add and remove line and exception breakpoints
* if a breakpoint is hit control must be passed to the ruby debugger
which sends xml to RDT and suspends the thread
* an API to get the information which the current implementation stores
in @frames, which is the binding, position and file name (next ot other
things) of every stack frame in every thread. The current traceProc uses
a Context object for every thread and @frames is an instance variable of
Context
* an API to set step or next mode. After the step or next is finished
the control must be passed to the ruby implemenation. The ruby
implementation must be able to differ between a hit breakpoint and a
step/next end
Unfortunately, I've no idea how the C implementation could be smuggled
into the interpreter and if there a way to get the C-function in place
without patching the ruby source code. On the other hand the gain in
usabality might be worth even a patch. It could even make it into the
ruby release (there must be other users which need fast tracing).
Don't hesitate to ask if you have further questions about eclipseDebug.rb
Markus
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Rubyeclipse-development mailing list
Rubyeclipse-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
