I have played with debug.rb a little bit and the results were a bit
disappointing. In my test 25% of the time was spent in the
DEBUGGER__::Context#trace_func whereas more than 50% was spent in the
ruby interpreter itself allocating memory and setting up parameters for
the call to the trace_func. This kind of explains why ArachnoRuby may
need a custom version of the Ruby interpreter for fast debugging.
So unless I am missing something, the interpreter itself needs a
speed-up first before we can talk about tuning up the RDT part. I would
think about C extension that would install its own event hook. The hook
would do most of the filtering work in C without calling the Ruby code.
More complicated than what Markus suggested but frankly I don't see an
alternative.
I guess more measurements need to be done.
Opinions?
Sasha
Joseph Moore wrote:
I did a but more diving into this and found that the default debug.rb
from Ruby is extremely slow (as you guys mentioned) and therefore
eclipseDebug.rb will be slow, too. Thank you for the extended detail,
though!
I have some emails out to the Ruby and Rails email lists about this as
well. Some people have mentioned the Arachno Ruby IDE, which is not
free, but I downloaded it and the debugger is fast. Maybe they would
license the debugger and allow it to be part of the RDT? If so I'll
drum up some donations for you!
I'll let you know if I hear anything more from the mailing lists.
-- Joe
On 1/9/06, *Markus Barchfeld* <
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
[EMAIL PROTECTED]
<mailto:[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
<http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>
_______________________________________________
Rubyeclipse-development mailing list
Rubyeclipse-development@lists.sourceforge.net
<mailto:Rubyeclipse-development@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
<https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development>
-------------------------------------------------------
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
