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

[Ludwig, Mark]

> From: Carl Lei (XeCycle)
> Sent: Thursday, September 22, 2011 1:10 AM
> Subject: Re: Performance problems (CPU 100%) with NULs in files
> 
> "Ludwig, Mark" <ludwig.mark@siemens.com> writes:
> 
> > I frequently encounter data files that are supposed to be 100%
> > ASCII but contain long sequences of NUL characters (ASCII zero).
> > (The reasons are out of my control.)
> >
> > When I first started using EMACS [sic] in 1980, I was delighted
> > to find it served as a very fine binary file editor.  It seems
> > that modern Emacs no longer is a fine binary file – at least not
> > by default.
> >
> > 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.
> >
> > Thanks!
> > Mark
> 
> What about trying `hexl-mode'?

Thanks for the pointer.  I was not aware of this mode.  This would be very 
helpful if I were actually intending to edit binary data.

In this thread, I am discussing simply visiting a file with the 
intention/belief that it's just ASCII.  I am not trying to change the text at 
all, just view it, scroll through it, etc.  (These are log files that should 
just be ASCII.)

Cheers,

Mark