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