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: RE: Performance problems (CPU 100%) with NULs in files Date: Sat, 24 Sep 2011 00:20:24 +0000 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1316823658 19941 80.91.229.12 (24 Sep 2011 00:20:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Sep 2011 00:20:58 +0000 (UTC) To: "help-gnu-emacs@gnu.org" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Sep 24 02:20:54 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 1R7FzA-0004j6-GC for geh-help-gnu-emacs@m.gmane.org; Sat, 24 Sep 2011 02:20:52 +0200 Original-Received: from localhost ([::1]:56433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7Fz9-0005DD-Kd for geh-help-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 20:20:51 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7Fz5-0005D6-Cs for help-gnu-emacs@gnu.org; Fri, 23 Sep 2011 20:20:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7Fz4-0006F7-CY for help-gnu-emacs@gnu.org; Fri, 23 Sep 2011 20:20:47 -0400 Original-Received: from usslmhub002.ugs.com ([134.244.32.85]:8975 helo=ugs.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7Fz4-0006F0-7m for help-gnu-emacs@gnu.org; Fri, 23 Sep 2011 20:20:46 -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; Fri, 23 Sep 2011 19:20:25 -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; Fri, 23 Sep 2011 19:20:24 -0500 Thread-Topic: Performance problems (CPU 100%) with NULs in files Thread-Index: Acx4opaN4QXNwclhR/W8cESA6FxoywASCq0SAFjrpzA= In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.122.220.137] X-detected-operating-system: by eggs.gnu.org: Windows 2000 SP2+, XP SP1+ (seldom 98) X-Received-From: 134.244.32.85 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:82321 Archived-At: > From: Eli Zaretskii > Subject: Re: Performance problems (CPU 100%) with NULs in files >=20 > > From: "Ludwig, Mark" > > Thread-Topic: Performance problems (CPU 100%) with NULs in files > > Date: Wed, 21 Sep 2011 21:08:42 +0000 > > > > 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. >=20 > Does it help to visit such files without code conversions, i.e. >=20 > M-x find-file-literally RET FILENAME RET >=20 > ? >=20 > If not, please file a bug report and attach to it an example file that > causes this slowdown. Thanks for the advice, but I have investigated and decided this is probably= too unusual to expect any "fix" for it. What I have found is that the "problem" is due to a "line" of text being ex= tremely long. In the test file I have, it is ~800,000 characters (bytes). = (It came to me with NULs, but I can replace those with any other printable= character and get the same result.) What I find is that some movement actions are rather slow -- take 4-7 secon= ds -- while others are extremely quick. Specifically, the "forward" moveme= nt actions (C-e, M-f) are slow, while the "backward" movement actions (C-a,= M-b) are instantaneous. Reposition (C-l) is also slow, as are the line-or= iented commands (C-p, C-n). Thinking through the magnitude of the oddity, I don't think it would be rea= sonable to expect Emacs to handle this any better than it does. It's just = gratifying that C-g works, so I can interrupt it when I stumble into some j= unk, and now that I know which actions are fast and slow, I can work around= it. OTOH, if you guys really think this is worth asking any developer to fix, I= 'll file a bug report. I don't need to send any data, because it's easy to= reproduce this behavior starting with an empty buffer. Thanks! Mark