GNU bug report logs -
#3219
Long Line Sluggishness
Previous Next
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.
Full log
Message #22 received at 3219 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 2 years and 300 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.