GNU bug report logs - #11943
24.1.50; Emacs unusably slow when looking at large files (bidi support at fault)

Previous Next

Full log

Message #19 received at 11943-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 11943-done <at> debbugs.gnu.org
Subject: Re: bug#11943: 24.1.50;
	Emacs unusably slow when looking at large files (bidi support
	at	fault)
Date: Sun, 15 Jul 2012 17:47:18 +0300

> Date: Sat, 14 Jul 2012 20:31:03 -0700
> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 11943 <at> debbugs.gnu.org
> 
> > On Sun, 15 Jul 2012 06:04:47 +0300
> > Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Dima Kogan <dima <at> secretsauce.net>
> > > 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.

Previous Next

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