From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ludwig, Mark" Newsgroups: gmane.emacs.help Subject: Performance problems (CPU 100%) with NULs in files Date: Wed, 21 Sep 2011 21:08:42 +0000 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_BC5672F8AD4C054BAF167C9801500D1A510C1869USSLMMBX003netp_" X-Trace: dough.gmane.org 1316665283 16173 80.91.229.12 (22 Sep 2011 04:21:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Sep 2011 04:21:23 +0000 (UTC) To: "help-gnu-emacs@gnu.org" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Sep 22 06:21:19 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R6amk-0001NK-PJ for geh-help-gnu-emacs@m.gmane.org; Thu, 22 Sep 2011 06:21:19 +0200 Original-Received: from localhost ([::1]:60955 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6amk-0008FG-3m for geh-help-gnu-emacs@m.gmane.org; Thu, 22 Sep 2011 00:21:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6ULo-0003LO-Mb for help-gnu-emacs@gnu.org; Wed, 21 Sep 2011 17:29:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6ULm-0005SP-Qw for help-gnu-emacs@gnu.org; Wed, 21 Sep 2011 17:29:04 -0400 Original-Received: from usslmhub002.ugs.com ([134.244.32.85]:33308 helo=ugs.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6ULm-0005S5-Jk for help-gnu-emacs@gnu.org; Wed, 21 Sep 2011 17:29:02 -0400 Original-Received: from USSLMMBX002.net.plm.eds.com (161.134.138.62) by USSLMHUB002.net.plm.eds.com (134.244.32.85) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Sep 2011 16:08:44 -0500 Original-Received: from USSLMMBX003.net.plm.eds.com ([169.254.2.147]) by USSLMMBX002.net.plm.eds.com ([169.254.1.150]) with mapi id 14.01.0323.003; Wed, 21 Sep 2011 16:08:44 -0500 Thread-Topic: Performance problems (CPU 100%) with NULs in files Thread-Index: Acx4opaN4QXNwclhR/W8cESA6Fxoyw== Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.122.71.27] X-detected-operating-system: by eggs.gnu.org: Windows 2000 SP2+, XP SP1+ (seldom 98) X-Received-From: 134.244.32.85 X-Mailman-Approved-At: Thu, 22 Sep 2011 00:21:03 -0400 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:82281 Archived-At: --_000_BC5672F8AD4C054BAF167C9801500D1A510C1869USSLMMBX003netp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I frequently encounter data files that are supposed to be 100% ASCII but co= ntain 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 lo= nger is a fine binary file - at least not by default. What happens is that as I scroll through the file, when the NULs are visibl= e, Emacs gets into some intensive processing for a long time (minutes, some= times!). 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 u= s-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 l= egitimate bug. I'm just concerned that it's a "feature" of some sort, thou= gh I hope not. Thanks! Mark --_000_BC5672F8AD4C054BAF167C9801500D1A510C1869USSLMMBX003netp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 wa= s delighted to find it served as a very fine binary file editor.  It s= eems 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, w= hen the NULs are visible, Emacs gets into some intensive processing for a l= ong time (minutes, sometimes!).  It eventually unwinds and repaints th= e display, but any movement of point sends it into this loop again.  I have found that M-< or M-> will qui= ckly reposition away from the problem (assuming the beginning and/or end of= the file do not contain NULs).  Most other movement operations send i= t 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 CP= U consumption problem.  Does anyone know how to solve this?  I= 217;ll file a bug report if this is a legitimate bug.  I’m just concerned that it’s a “feature” of some s= ort, though I hope not.

 

Thanks!

 

Mark

 

--_000_BC5672F8AD4C054BAF167C9801500D1A510C1869USSLMMBX003netp_--