Re: backtrace-mode

[Gemini Lasswell <geminilasswell@runbox.com>]

Helmut Eller <eller.helmut@gmail.com> writes:

> So I think there
> should either be a proper "view source" command or xref backend for
> backtraces.

I agree.  I think there should be three commands:

1. "View source", to jump to the source for the frame at point.  I
haven't done it yet but I plan on implementing it and binding it to
the 's' key.  For now it is going to work best with Edebug, but when
the byte compiler or Lisp reader gain the ability someday to save
source code positions, it could be made to work with those as well.

2. "Go to definition", to jump to the source code for the definition
of the symbol at point, which can be used on any function or variable
name in the buffer.  I think xref-find-definitions with the Elisp
backend works well for this.

3. "Show help", to bring up help for the symbol at point, currently
implemented by backtrace-help-follow-symbol, bound to RET.

> Another issue: backtrace-get-frames seems to compute the entire
> backtrace and all possibly relevant information in advance.  Maybe that
> should be done a bit more lazily, e.g. compute the next N frames only if
> somebody needs them.  For local variable also keep in mind that
> backtrace--locals is implemented rather inefficiently.  That would also
> be less problematic if locals are only fetched when needed.

I'm aware that there's an O(n^2) here but I didn't want to prematurely
optimize and make the code more complicated without noticable benefit.
While working on this code I had tried generating backtraces from
max-lisp-eval-depth errors a few times and they always came up
quickly.  Yesterday I realized that was due to a bug, now on debbugs
as #31919.  With that fixed I tried wrapping the calls to
backtrace-get-frames and backtrace-print with benchmark-run, and
then evaluating this code:

(toggle-debug-on-error)
(defun my-func (arg)
  (let ((arg1 arg))
    (+ (length arg) (my-func arg))))

And then I tried both (my-func "hello") and (my-func my-str) with
my-str bound to the buffer-string of a magit-status buffer, which 
for the one I used made (length (cl-prin1-to-string my-str)) evaluate
to 1711302, and which is the sort of value which would make previous
versions of Emacs backtraces excruciatingly slow.

From my experiments I concluded backtrace-get-frames is not a
performance problem.  With standard stack limits it takes about 0.015
seconds, and even after increasing both max-lisp-eval-depth and
max-specpdl-size by a factor of 5, it still only takes 0.2 seconds (on
a 5-year old Intel cpu, 2.6GHz).  But backtrace-print is far slower,
taking 3.7 seconds with high stack limits and "hello" and 60 seconds
with default stack limits and the magit buffer-string.  So I'll look
into what can be done lazily when rendering the backtrace frames into
the buffer.

Gemini