GNU bug report logs - #3219
Long Line Sluggishness

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 3219 in the body.
You can then email your comments to 3219 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: Long Line Sluggishness
Date: Tue, 5 May 2009 08:44:05 -0400

Emacs becomes extremely sluggish when long lines are used.

To reproduce:
Emacs -Q
Enter long line through recursive copy/paste  (about 700k characters  
in my example)
- use vertical scrollbar to scroll to the bottom   -> doesn't work
- use End key to scroll to bottom

Now move around, enter text, scroll up, etc: everything happens with a  
substantial (0.5-1.0 seconds) delay.

For a more practical example: I was working in lisp-interaction-mode,  
typing C-j after "load-history", and expanding one of the "..."  
ellipses. This gave me a line in excess of 100k.

Similarly, users might want to edit long (mostly binary) files.  But  
maybe that's a corner case, and it would be okay to change C-j a bit  
to format the output better.

This is not a regression compared to Emacs 22 (comparing to Carbon  
port).




In GNU Emacs 23.0.92.19 (i386-apple-darwin9.6.0, NS apple-appkit-949.43)
 of 2009-04-30 on SCARLETT.PSY.CMU.EDU
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns' '--without-x' 'CFLAGS=- 
DMAC_OS_X_VERSION_MIN_REQUIRED=1040  -O3''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_US.US-ASCII
  value of $LC_CTYPE: en_US.US-ASCII
  value of $LC_MESSAGES: en_US.US-ASCII
  value of $LC_MONETARY: en_US.US-ASCII
  value of $LC_NUMERIC: en_US.US-ASCII
  value of $LC_TIME: en_US.US-ASCII
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: us-ascii-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
s-v s-v s-v s-v s-v s-v s-v s-v s-v s-v <wheel-up>
<double-wheel-up> <triple-wheel-up> <triple-wheel-up>
<wheel-up> <double-wheel-up> <triple-wheel-up> <triple-wheel-up>
<triple-wheel-up> s-a s-c <wheel-down> <double-wheel-down>
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down>
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down>
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down>
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down>
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down>
<triple-wheel-down> <triple-wheel-down> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<mouse-1> C-SPC <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <down-mouse-1> <down-mouse-1> <down-mouse-1>
<down-mouse-1> <mouse-1> <end> s-c SPC s-v SPC s-v
SPC s-v s-v s-v s-v s-v s-v s-v <wheel-up> <double-wheel-up>
<wheel-up> <double-wheel-up> <down-mouse-1> <mouse-1>
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1>
<wheel-up> <double-wheel-up> <wheel-up> <double-wheel-up>
<wheel-up> <double-wheel-up> <escape> x r e p o r t
- b <tab> <return>

Recent messages:
byte-code: Beginning of buffer [5 times]
byte-code: End of buffer [5 times]
byte-code: Beginning of buffer [4 times]
byte-code: End of buffer [6 times]
Mark set [114 times]
Saved text until "lled through super interpretKeyEvents:])"
byte-code: End of buffer
Mark set [2 times]
Saved text from "per interpretKeyEvents:]) <NSTextInput> "
Mark set [9 times]

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Jerome L Quinn <jlquinn <at> us.ibm.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 15555 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 3219 <at> debbugs.gnu.org
Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines
Date: Tue, 26 Jan 2016 00:13:01 -0500

Jerome L Quinn <jlquinn <at> us.ibm.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> wrote on 10/09/2013 12:59:26 PM:
>
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> To: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: Jerome L Quinn/Watson/IBM <at> IBMUS, 15555 <at> debbugs.gnu.org
>> Date: 10/09/2013 12:59 PM
>> Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines
>> 
>> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> > Cc: Jerome L Quinn <jlquinn <at> us.ibm.com>, 15555 <at> debbugs.gnu.org
>> > Date: Wed, 09 Oct 2013 08:26:58 -0400
>> > 
>> > >> And disabling bidi reordering completely eliminates the bad behavior.
>> > > If you can afford that, go for it.
>> > 
>> > IIRC this is the first report where setting bidi-display-reordering to
>> > nil is really the best recommendation we can offer (and where it
>> > apparently indeed helps significantly).
>> 
>> Actually, it's not my recommendation. But the OP keeps claiming that
>> nothing else works for him.
>> 
>> My recommendation would be rather to make lines shorter.
>
> I can't make the lines shorter. The file I'm looking at is computer-generated.
>
> I can disable reordering, which does solve the speed problem for me. I'd just like
> to help identify the source of the issue so that it can be resolved at some point.
>
>> > I consider bidi-display-reordering as a debugging tool rather than
>> > a user config, so I'm not very happy about this situation.
>> 
>> I'm not happy either (probably even less than you), but I'm not going
>> to agree that slow redisplay of 14K-character lines has anything to do
>> with bidirectional editing support. _Anything_ that slows down
>> redisplay even a bit will have the same effect with such long lines,
>> e.g., JIT font lock, Flyspell, invisible text, you name it. In fact,
>> even on a reasonably fast machine (mine is a core i7 screamer) Emacs
>> is unbearably slow with such long lines without reordering as well.
>> Maybe the OP has an unreasonably fast machine, but that just makes his
>> use case even more rare.
>
> I'm not sure what else I can do. I timed how long it takes to page down and
> move the cursor and it's much slower with reordering enabled on my test
> case.
>
> No, moving around with 14K lines and reordering off is not lightning fast. It
> is however subsecond response on my machine. Reordering brings subsecond
> response up to multiple seconds as you are further along the line.
>
> I am on a high-end 12 core xeon machine, so yes, the hardware is fast.

FWIW, on Emacs 25 on Mac OS X, the bidi text as reported in the initial
bug is still very slow.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: jlquinn <at> us.ibm.com, 15555 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 3219 <at> debbugs.gnu.org
Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines
Date: Tue, 26 Jan 2016 16:41:10 +0200

> From: Andrew Hyatt <ahyatt <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  3219 <at> debbugs.gnu.org,  15555 <at> debbugs.gnu.org,  Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Tue, 26 Jan 2016 00:13:01 -0500
> 
> FWIW, on Emacs 25 on Mac OS X, the bidi text as reported in the initial
> bug is still very slow.

Nothing was done since then to speed up redisplay for such long lines.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 40007 <at> debbugs.gnu.org, 3219 <at> debbugs.gnu.org
Subject: Re: bug#40007: 28.0.50; Emacs gets very slow when displaying a long
 line
Date: Sat, 23 Jul 2022 10:59:00 +0200

David Reitter <david.reitter <at> gmail.com> writes:

> Emacs becomes extremely sluggish when long lines are used.

These issues have been fixed in Emacs 29 -- long lines no longer slows
down Emacs (to these degrees), so I'm closing this bug report.

There may be issues remaining with long lines, and if so, please open
new bug reports for those issues (and cases for reproduction would be
appreciated).

Previous Next

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