bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15555: 24.3; Bidirectional display very slow with long lines


From: Jerome L Quinn
Subject: bug#15555: 24.3; Bidirectional display very slow with long lines
Date: Tue, 8 Oct 2013 11:39:58 -0400

Eli Zaretskii <address@hidden> wrote on 10/08/2013 02:42:53 AM:

> From: Eli Zaretskii <address@hidden>

> To: Jerome L Quinn/Watson/address@hidden
> Cc: address@hidden
> Date: 10/08/2013 02:43 AM
> Subject: Re: bug#15555: 24.3; Bidirectional display very slow with long lines
>
> > From: Jerome L Quinn <address@hidden>
> > 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]