From: "Ludwig, Mark" <ludwig.mark@siemens.com>
To: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Subject: RE: Performance problems (CPU 100%) with NULs in files
Date: Thu, 22 Sep 2011 12:58:16 +0000 [thread overview]
Message-ID: <BC5672F8AD4C054BAF167C9801500D1A510C1E33@USSLMMBX003.net.plm.eds.com> (raw)
In-Reply-To: <87k491kt05.fsf@gmail.com>
> 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
prev parent reply other threads:[~2011-09-22 12:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 21:08 Performance problems (CPU 100%) with NULs in files Ludwig, Mark
2011-09-22 4:30 ` Drew Adams
2011-09-22 13:00 ` Ludwig, Mark
2011-09-22 5:44 ` Eli Zaretskii
2011-09-22 12:58 ` Ludwig, Mark
2011-09-24 0:20 ` Ludwig, Mark
2011-09-24 0:50 ` Le Wang
2011-09-24 6:04 ` Eli Zaretskii
2011-09-24 13:32 ` Ludwig, Mark
2011-09-24 14:15 ` Eli Zaretskii
2011-09-22 6:09 ` XeCycle
2011-09-22 12:58 ` Ludwig, Mark [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BC5672F8AD4C054BAF167C9801500D1A510C1E33@USSLMMBX003.net.plm.eds.com \
--to=ludwig.mark@siemens.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).