GNU bug report logs - #3219
Long Line Sluggishness

Previous Next

Package: emacs;

Reported by: David Reitter <david.reitter <at> gmail.com>

Date: Tue, 5 May 2009 12:50:03 UTC

Severity: normal

Merged with 4123, 9589, 13675, 15555, 18530, 22143, 24523, 30457, 32523, 40007

Found in versions 23.1, 24.2, 24.2.93, 24.3, 24.5, 26.0.91, 27.0.50, 28.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#3219; Package emacs. (Tue, 05 May 2009 12:50:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Reitter <david.reitter <at> gmail.com>:
New bug report received and forwarded. Copy sent to Emacs Bugs <bug-gnu-emacs <at> gnu.org>. (Tue, 05 May 2009 12:50:03 GMT) Full text and rfc822 format available.

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]





Merged 3219 4123. Request was from Chong Yidong <cyd <at> stupidchicken.com> to control <at> emacsbugs.donarmstrong.com. (Sat, 15 Aug 2009 05:25:05 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 24 Sep 2011 01:46:01 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589 13675. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Sun, 10 Feb 2013 20:45:02 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589 13675 15555. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 10 Feb 2014 21:29:01 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589 13675 15555 16786. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 18 Feb 2014 00:56:02 GMT) Full text and rfc822 format available.

Disconnected #16786 from all other report(s). Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 18 Feb 2014 07:33:02 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589 13675 15555 18530. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 23 Sep 2014 09:51:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#3219; Package emacs. (Tue, 26 Jan 2016 05:14:02 GMT) Full text and rfc822 format available.

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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#3219; Package emacs. (Tue, 26 Jan 2016 14:42:01 GMT) Full text and rfc822 format available.

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.




Merged 3219 4123 9589 13675 15555 18530 24523. Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 24 Sep 2016 11:33:02 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589 13675 15555 18530 24523 30457. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Wed, 14 Feb 2018 19:56:02 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589 13675 15555 18530 24523 30457 40007. Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 10 Mar 2020 14:41:02 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589 13675 15555 18530 24523 30457 32523 40007. Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Fri, 21 Aug 2020 17:07:01 GMT) Full text and rfc822 format available.

Merged 3219 4123 9589 13675 15555 18530 22143 24523 30457 32523 40007. Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Fri, 21 Aug 2020 17:43:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#3219; Package emacs. (Sat, 23 Jul 2022 09:00:02 GMT) Full text and rfc822 format available.

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





bug marked as fixed in version 29.1, send any further explanations to 40007 <at> debbugs.gnu.org and Jan Synacek <jsynacek <at> redhat.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 23 Jul 2022 09:00:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 20 Aug 2022 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 211 days ago.

Previous Next


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