Eli Zaretskii wrote on 10/08/2013 02:42:53 AM: > From: Eli Zaretskii > To: Jerome L Quinn/Watson/IBM@IBMUS > Cc: 15555@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 > > 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