GNU bug report logs - #18558
24.4.50; Debugger slow with long strings

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18558 in the body.
You can then email your comments to 18558 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; Debugger slow with long strings
Date: Thu, 25 Sep 2014 11:16:11 +0200

Moving the cursor in the debugger window is very slow in the following
example:

shell> cat test.el
(progn
  (defun foo (n string)
    (cond ((= n 0) (debug))
          (t (foo (1- n) string))))
  (foo 30 (make-string 500000 ?\\)))

shell> emacs -Q -nw -l test.el

Now move the cursor around to see the slowness.

Maybe the debugger should truncate long strings as it does with long
lists.


In GNU Emacs 24.4.50.2 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2014-09-08 on ix

Message #8 received at 18558 <at> debbugs.gnu.org (full text, mbox):

From: Marcin Borkowski <mbork <at> mbork.pl>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 18558 <at> debbugs.gnu.org
Subject: Re: bug#18558: 24.4.50; Debugger slow with long strings
Date: Fri, 19 Feb 2016 09:41:01 +0100

On 2014-09-25, at 12:16, Helmut Eller <eller.helmut <at> gmail.com> wrote:

> Moving the cursor in the debugger window is very slow in the following
> example:
>
> shell> cat test.el
> (progn
>   (defun foo (n string)
>     (cond ((= n 0) (debug))
>           (t (foo (1- n) string))))
>   (foo 30 (make-string 500000 ?\\)))
>
> shell> emacs -Q -nw -l test.el
>
> Now move the cursor around to see the slowness.
>
> Maybe the debugger should truncate long strings as it does with long
> lists.

Confirmed on GNU Emacs 25.1.50.2 (commit 4ccd268).

I would guess that the problem is not in long string /per se/, but with
lon lines in the *Backtrace* buffer, i.e. probably something connected
with the display engine.  I guess this bug should either be closed or
merged with some other one (one of the other ones, perhaps) dealing with
efficiency problems with long lines.

Best,

-- 
mbork

Message #11 received at 18558 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: 18558 <at> debbugs.gnu.org, eller.helmut <at> gmail.com
Subject: Re: bug#18558: 24.4.50; Debugger slow with long strings
Date: Fri, 19 Feb 2016 11:03:41 +0200

> From: Marcin Borkowski <mbork <at> mbork.pl>
> Date: Fri, 19 Feb 2016 09:41:01 +0100
> Cc: 18558 <at> debbugs.gnu.org
> 
> On 2014-09-25, at 12:16, Helmut Eller <eller.helmut <at> gmail.com> wrote:
> 
> > Moving the cursor in the debugger window is very slow in the following
> > example:
> >
> > shell> cat test.el
> > (progn
> >   (defun foo (n string)
> >     (cond ((= n 0) (debug))
> >           (t (foo (1- n) string))))
> >   (foo 30 (make-string 500000 ?\\)))
> >
> > shell> emacs -Q -nw -l test.el
> >
> > Now move the cursor around to see the slowness.
> >
> > Maybe the debugger should truncate long strings as it does with long
> > lists.
> 
> Confirmed on GNU Emacs 25.1.50.2 (commit 4ccd268).
> 
> I would guess that the problem is not in long string /per se/, but with
> lon lines in the *Backtrace* buffer, i.e. probably something connected
> with the display engine.  I guess this bug should either be closed or
> merged with some other one (one of the other ones, perhaps) dealing with
> efficiency problems with long lines.

Yes, please merge it.

Thanks.

Message #14 received at 18558 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: 18558 <at> debbugs.gnu.org
Subject: Re: bug#18558: 24.4.50; Debugger slow with long strings
Date: Fri, 19 Feb 2016 10:15:44 +0100

On Fri, Feb 19 2016, Marcin Borkowski wrote:

> I would guess that the problem is not in long string /per se/, but with
> lon lines in the *Backtrace* buffer, i.e. probably something connected
> with the display engine.  I guess this bug should either be closed or
> merged with some other one (one of the other ones, perhaps) dealing with
> efficiency problems with long lines.

It seems very unlikely that the general "long-lines" problem of the
display engine will be fixed.  In contrast, the debugger could be
changed to not generate long lines, e.g. by truncating long string like
it does for long/cyclic lists.

Helmut

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.