RE: Performance problems (CPU 100%) with NULs in files

["Ludwig, Mark" <ludwig.mark@siemens.com>]

> From: Drew Adams [mailto:drew.adams@oracle.com]
> Subject: RE: Performance problems (CPU 100%) with NULs in files
> 
> > What happens is that as I scroll through the file, when
> > the NULs are visible, Emacs gets into some intensive
> > processing for a long time (minutes, sometimes!).  It
> > eventually unwinds and repaints the display, but any
> > movement of point sends it into this loop again.  I have
> > found that M-< or M-> will quickly reposition away from
> > the problem (assuming the beginning and/or end of the file
> > do not contain NULs).  Most other movement operations send
> > it into the loop.
> >
> > I understand about encodings, and have messed around with
> > forcing it into us-ascii, but it appears not to be related
> > to this CPU consumption problem.  Does anyone know how to
> > solve this?  I'll file a bug report if this is a legitimate bug.
> > I'm just concerned that it's a "feature" of some sort, though
> > I hope not.
> 
> Are you using the development version of Emacs (aka Emacs 24)?

No, I'm still on Emacs 23, but this behavior has been happening since at least Emacs 21, and perhaps longer than that.  (I've just never bothered to report it, because it wasn't affecting me very often.)

> If so, I have no idea whether this will help or help you find the
> problem, but
> you might try doing this to see if it makes a difference:
> 
> (setq-default bidi-display-reordering  nil)

This variable doesn't seem to exist in Emacs 23, which you probably were implying.  I tried setting it anyway, and it had no effect.  (Is it possible to have undefined/invisible variables that the code uses if they are brought into existence?)

> Others might have helpful suggestions.  In any case, especially if you
> have a
> reproducible case starting from `emacs -Q' (no init file), I'd suggest
> reporting
> a bug.  Emacs developers will be able to tell you whether there is
> really a bug.

The problem does reproduce with -Q.  It only happens where there are a significant number of NULs, though.  I am narrowing down the range to get to a minimal test case that shows the problem.

> Whatever Emacs version you are using, this sounds like a regression wrt
> the
> behavior you report with an older version.

Hehe.  I have no idea what Emacs version did NOT do this, other than being certain that it did not happen in the TECO-based EMACS in the 1980's....

Cheers,

Mark