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

Previous Next

Full log

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

From: Jerome L Quinn <jlquinn <at> us.ibm.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15555 <at> debbugs.gnu.org
Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines
Date: Tue, 8 Oct 2013 11:39:58 -0400

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

Eli Zaretskii <eliz <at> gnu.org> wrote on 10/08/2013 02:42:53 AM:

> From: Eli Zaretskii <eliz <at> gnu.org>
> To: Jerome L Quinn/Watson/IBM <at> IBMUS
> Cc: 15555 <at> debbugs.gnu.org
> Date: 10/08/2013 02:43 AM
> Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long
lines
>
> > From: Jerome L Quinn <jlquinn <at> us.ibm.com>
> > Date: Mon, 7 Oct 2013 16:05:42 -0400
> >
> > If I have a buffer with a very long line (14000 chars) with a mix of
> > ASCII and Arabic text, emacs gets painfully slow when point is further
> > along the line.
>
> Emacs is in general painfully slow with such long lines, even if there
> are only ASCII characters there.  Presence of Arabic characters makes
> it slower, but it is unbearably slow even before that.  This is a
> known deficiency of the Emacs display engine.  This is bug #13675.

Hi Eli,

I'm not sure it is the same bug.  When I disable the bidi reordering
variable,
navigation speed becomes reasonable, even with the very long line length.
I'm on a very fast machine, so #13675 may not be impacting me that badly.

When bidi reordering is enabled, it is multiple seconds to move the cursor
up
and down, which is unusable.


> > It looks like there's an N^2 algorithm dependent on the column of
> > point.
>
> No, there are no N² algorithms.  However, for many display operations,
> Emacs needs to go to the beginning of the previous _physical_ line,
> and then go forward to the place it needs to redisplay.  With very
> long lines, this takes a lot of time.
>
> If your data files don't include empty lines, there's perhaps another
> source of slowdown, which _is_ peculiar to bidirectional display:
> Emacs needs to find the beginning of the current paragraph to
> determine its "base direction".  To see if this is your problem, try
> setting bidi-paragraph-direction to either left-to-right or
> right-to-left, depending on whether most of the text should be read
> left to right or right to left.

Setting bidi-paragraph-direction to right-to-left improves the situation
some
but I'd still call it unusable in this situation.  Disabling reordering
makes
emacs as responsive as I'd expect, comparable to emacs23.

OK, I played with it a bit more.  I think the issue is exacerbated by
splitting
the frame into 2 side-by-side windows.

Try this:

Expand emacs to fill the screen.  For me this is 194x65.
Create a new buffer with just the text I included in the bug report.
C-x 3
Put something else in the left window and go the right window.
Page down several times.

The last page down I find takes 5-8 seconds repeatedly.

I don't see as bad behavior when the text is in the left buffer or if I
have only
1 window.

And disabling bidi reordering completely eliminates the bad behavior.


Thanks
Jerry

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