On Fri, May 24, 2002 at 01:50:22AM +0900, Jean-Hugues ROBERT wrote:
> Unfortunately I discovered that ruby standard debugger is somehow too
> slow to be usable but in simple cases. I suspect that there are ways
> to make it much faster with some C code that would take over the current
> set_trace_proc mechanism:
> 
> A) An extended caller() with bindings in the result
> B) set_trace_proc( some_file, some_line_no ) { gets here when line reached }

I think it could be a lot faster if call_trace_func() were replaced with
a function pointer.  This would allow a trace func to be implemented
easily in C (instead of the way it is now, where the call still has to
be a Ruby function).  By default, that function pointer could point to
call_trace_func.

I think where much of the speed hit comes from is in the many many calls
to rb_f_binding.  The debugger appears to make use of the binding, so
the trick is to reduce the number of bindings created.  There are only a
few cases where the binding is actually needed.  The binding can be
created either by calling rb_f_binding() (which would need to be exposed
by making it non-static) or by calling the original call_trace_func
(which would also need to be non-static).

A C replacement for call_trace_func must also be VERY careful to not
call any ruby functions (particularly functions that might raise
exceptions).  From what I can tell, the current call_trace_func goes to
a lot of trouble to make sure that it cleans up after itself.
(Solution: if you want to make calls into ruby, do it by first calling
the original call_trace_func and having it do the actual call).

There's probably a lot more to consider, and a lot that can go wrong,
and a little more of the Ruby interpreter needs to be exposed to the C
extension.  I'm not sure whether or not the time required to put into
speeding up the debugger would by the time gained by having a faster
debugger.

Paul