bug#36566: 27.0.50; debug is sometimes horribly slow

[Gemini Lasswell <gazally@runbox.com>]

Noam Postavsky <npostavs@gmail.com> writes:

>> Subject: [PATCH 2/5] Improve performance of backtrace printing (bug#36566)
>>
>> * lisp/emacs-lisp/cl-print.el (cl-print-to-string-with-limit): Reduce
>> print-level and print-length more quickly when the structure being
>> printed is very large.
>
> Is this one still needed?  I tried reverting it, and it seems to make no
> noticeable difference now (I didn't really measure though, I can't think
> of a straightforward way of doing that), at least for the case that
> Michael posted.

My straightforward way of doing that is

M-: (benchmark-run (revert-buffer))  RET

while the backtrace buffer is current.

I tried, with and without the patch, these steps:

Navigate to org-export--prune-tree in ox.el.
C-M-x to instrument it with Edebug.
Open a 150K org-mode file.
C-c C-e h H
Edebug to line 2728 of ox.el (inside the lambda bound to 'walk-data').
Use 'd' to get a backtrace. 
M-: (benchmark-run (revert-buffer)) RET

With the patch: (0.594630583 9 0.31395808699999783)
Without the patch: (0.925387816 15 0.5158638049999986)

I would expect that debugging deeper into org-mode export (so that there
are more frames to display containing the org parse tree) with a larger
org-mode file would exaggerate the difference.

Edebug is very sluggish debugging org-export--prune-tree because it is
sending some 400K lines to the echo area, and then those make *Messages*
redisplay slow.  I will work on another patch to improve Edebug's
behavior in this case.

>> Subject: [PATCH 4/5] Create common tests for print.c and cl-print.el
>
> Extra colon.
>
>> Subject: [PATCH 5/5] Don't build print-number-table unless it will be used
>
> We try not to use hashes to reference commits
>

I'll fix the patch comments as you suggest.