GNU bug report logs - #15555
24.3; Bidirectional display very slow with long lines

Previous Next

Full log

View this message in rfc822 format

From: Jerome L Quinn <jlquinn <at> us.ibm.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15555 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#15555: 24.3; Bidirectional display very slow with long lines
Date: Wed, 9 Oct 2013 14:04:12 -0400

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Previous Next

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