bug#36566: 27.0.50; debug is sometimes horribly slow

[Noam Postavsky]

Gemini Lasswell <gazally@runbox.com> writes:

> 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 actually get 0.9 vs 1.3 seconds (the latter being with patch 2/5
reverted) with Michael's example, which is more of a difference than I
expected based on my non-timed trials.

> 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.

Alright, it's probably enough to justify this.

> 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.

Okay, there's nothing more from my side, so I guess you can go ahead and
push when ready.