Subject: Re: bug#11943: 24.1.50; Emacs unusably slow when looking at large files (bidi support at fault)

From: Eli Zaretskii <[email-masked]>
Date: Sun, 15 Jul 2012 17:47:18 +0300

> Date: Sat, 14 Jul 2012 20:31:03 -0700
> From: Dima Kogan <[email-masked]>
> Cc: [email-masked]
> 
> > On Sun, 15 Jul 2012 06:04:47 +0300
> > Eli Zaretskii <[email-masked]> wrote:
> >
> > > From: Dima Kogan <[email-masked]>
> > > Date: Sat, 14 Jul 2012 17:50:51 -0700
> > > 
> > > I'm observing that when some large text files are loaded, emacs
> > > slows to a crawl. As an example, I have a 14MB file open (with
> > > emacs -Q). Every time I do (next-line) or (previous-line) it takes
> > > a few seconds. This is a > 2GHz Core2 machine, so there's no reason
> > > for this to happen. 'M-x benchmark' says that (previous-line) takes
> > > >2s each time. I discovered that if I do (setq
> > > >bidi-display-reordering nil) then emacs is snappy
> > > again, with previous-line taking <1ms.
> > > 
> > > The specific file I'm using to exhibit the bug consists of many
> > > repeated stanzas such as
> > > 
> > > =========================
> > > {
> > >  {2.222222,2.222222,2.222222,2.2},
> > >  {-2.222222,2.222222,2.222222},
> > >  {-22.222222,22.222222,2.222222}
> > > },
> > > =========================
> > > 
> > > without the =. Saving a stanza into a file called 'snippet', the
> > > 14MB file can be made with
> > > 
> > > $ for i in `seq 17`; do cat snippet snippet > xxx; mv xxx snippet;
> > > done
> > 
> > What is the major mode in the buffer where you see this?  I mean the
> > real-life example where you bumped into this, not the 'snippet' file
> > produced by the above.
> 
> fundamental-mode

The recommended way to handle such buffers is to set
bidi-paragraph-direction to left-to-right.  Major modes for editing
program source, that inherit from prog-mode, already do that
automatically, but fundamental-mode does not (and can not, IMO).
That's why I asked you about the major mode.

Anyway, to avoid such catastrophic slow-downs, I made a change in the
code that determines base paragraph direction, and committed those
changes as trunk revision 109098.  With those changes, redisplay
should be again fast, even with bidi-paragraph-direction at its
default nil value.

Thanks.