all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Gemini Lasswell <gazally@runbox.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: 36566@debbugs.gnu.org, Noam Postavsky <npostavs@gmail.com>
Subject: bug#36566: 27.0.50; debug is sometimes horribly slow
Date: Sat, 13 Jul 2019 17:02:19 -0700	[thread overview]
Message-ID: <877e8llbzo.fsf@runbox.com> (raw)
In-Reply-To: <87r26xjyon.fsf@web.de> (Michael Heerdegen's message of "Thu, 11 Jul 2019 00:46:00 +0200")

Michael Heerdegen <michael_heerdegen@web.de> writes:

> With print-gemsym -> nil, the debugger needs approx. 2 seconds here to
> pop up, and with print-gemsym -> t, approx. 12.  So I wonder why this
> setting makes it that slow - I would expect a small time penalty, but
> such a big difference?

The C printing code builds hash tables to match gensyms to the numbers
they are printed with.  So it is building and discarding these hash
tables which causes the garbage collection and the slowdown.  Emacs 26's
backtrace printing is also significantly slower with print-gensym turned
on.

The reason master is so much slower than Emacs 26 is because of the
adaptive abbreviating I added to reduce problems with really long lines.
In Emacs 26 it's hard to debug things like magit or org-mode because
lines in the backtrace can easily get to be thousands or millions of
characters long and display gets really slow.  When I added
backtrace-mode, I gave it a target line length and a function which
starts with guesses at the appropriate values of print-length and
print-level, and which iteratively prints using those values, and if the
length of the printed representation is over the target, it reduces
print-length and print-level and tries again.  That reprinting, and
consequential repeated construction of gensym hash tables, is what's
making master slower than Emacs 26 in this case.

I remember when I was writing that function thinking that it was a
heuristic sort of algorithm and would likely need tweaking, so here we
are.

The easy fix for you for today is to set backtrace-line-length to 100 or
less, which will make the initial values of print-length and print-level
so low that little reprinting will be done.  Then use
backtrace-expand-ellipsis (bound to "."), with or without C-u, on the
lines where you want to see the full data structure.  And try "+" and
"-" if you haven't already.

I'll experiment with tweaking the heuristic to reduce the amount of
reprinting it does, and let you know what I come up with.

> BTW, extra points if the debugger provided commands/ a menu to tune such
> settings (like printing variables) live when using it.

There is such a command for print-circle (bound to "#") and it would be
easy to add one for print-gensym, although I could use a keybinding
suggestion.  backtrace-line-length is a defcustom.






  reply	other threads:[~2019-07-14  0:02 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10  3:09 bug#36566: 27.0.50; debug is sometimes horribly slow Michael Heerdegen
2019-07-10  3:18 ` Drew Adams
2019-07-10 11:20 ` Noam Postavsky
2019-07-10 22:46   ` Michael Heerdegen
2019-07-14  0:02     ` Gemini Lasswell [this message]
2019-07-15  2:05       ` Michael Heerdegen
2019-08-01  1:06         ` Gemini Lasswell
2019-08-01  0:53       ` Gemini Lasswell
2019-08-01  1:05         ` Noam Postavsky
2019-08-05 19:53           ` Gemini Lasswell
2019-08-19  1:30             ` Noam Postavsky
2019-09-06 16:41               ` Gemini Lasswell
2019-09-11  2:54                 ` Noam Postavsky
2019-09-13 21:08                   ` Gemini Lasswell
2019-09-14 13:44                     ` Mauro Aranda
2019-09-14 14:05                       ` Eli Zaretskii
2019-09-14 14:16                         ` Mauro Aranda
2019-09-14 15:47                           ` Eli Zaretskii
2022-04-25 14:41                     ` Lars Ingebrigtsen
2022-04-25 23:23                       ` Michael Heerdegen
2022-04-27  0:37                       ` Gemini Lasswell
2022-04-27  4:42                         ` Michael Heerdegen
2022-04-27 12:28                           ` Lars Ingebrigtsen
2022-04-28 17:56                             ` Gemini Lasswell
2022-05-13 16:01                               ` Lars Ingebrigtsen
2022-05-14  3:57                                 ` Michael Heerdegen
2022-05-14 11:35                                   ` Lars Ingebrigtsen
2022-05-14 13:52                                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-14 15:45                                       ` Lars Ingebrigtsen
2022-05-14 16:05                                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-14 16:18                                           ` Lars Ingebrigtsen
2022-05-14 16:54                                             ` Lars Ingebrigtsen
2022-05-14 18:55                                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-15 12:25                                                 ` Lars Ingebrigtsen
2022-05-15 13:33                                                   ` Lars Ingebrigtsen
2022-05-15 16:13                                                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-15 16:25                                                     ` Lars Ingebrigtsen
2022-05-15 16:52                                                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-16  1:00                                                         ` Lars Ingebrigtsen
2022-05-16  1:39                                                           ` Michael Heerdegen
2022-05-16  1:44                                                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-16 12:11                                                             ` Lars Ingebrigtsen
2022-05-15  7:47                                           ` Rudolf Schlatte
2022-05-15 12:28                                             ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877e8llbzo.fsf@runbox.com \
    --to=gazally@runbox.com \
    --cc=36566@debbugs.gnu.org \
    --cc=michael_heerdegen@web.de \
    --cc=npostavs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.