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 13:32:10 +0000 Message-ID: References: <83aa9uqxwg.fsf@gnu.org> 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 1316871154 20301 80.91.229.12 (24 Sep 2011 13:32:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Sep 2011 13:32:34 +0000 (UTC) To: Eli Zaretskii , "help-gnu-emacs@gnu.org" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Sep 24 15:32:27 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 1R7SLB-0002ZU-MR for geh-help-gnu-emacs@m.gmane.org; Sat, 24 Sep 2011 15:32:25 +0200 Original-Received: from localhost ([::1]:45958 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7SLB-0003pY-7W for geh-help-gnu-emacs@m.gmane.org; Sat, 24 Sep 2011 09:32:25 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7SL7-0003pL-2d for help-gnu-emacs@gnu.org; Sat, 24 Sep 2011 09:32:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7SL6-0004mx-1p for help-gnu-emacs@gnu.org; Sat, 24 Sep 2011 09:32:21 -0400 Original-Received: from usslmhub002.ugs.com ([134.244.32.85]:48421 helo=ugs.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7SL5-0004ml-Ug for help-gnu-emacs@gnu.org; Sat, 24 Sep 2011 09:32:20 -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; Sat, 24 Sep 2011 08:32:10 -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; Sat, 24 Sep 2011 08:32:10 -0500 Thread-Topic: Performance problems (CPU 100%) with NULs in files Thread-Index: Acx4opaN4QXNwclhR/W8cESA6FxoywASCq0SAFjrpzAAFtCpgAAFEsTQ In-Reply-To: <83aa9uqxwg.fsf@gnu.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.122.220.71] 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:82330 Archived-At: I filed bug#9589 before your message. Since you know about this sort of pr= oblem generally, I assume the description will make sense. Cheers, Mark -----Original Message----- From: help-gnu-emacs-bounces+ludwig.mark=3Dsiemens.com@gnu.org [mailto:help= -gnu-emacs-bounces+ludwig.mark=3Dsiemens.com@gnu.org] On Behalf Of Eli Zare= tskii Sent: Saturday, September 24, 2011 1:04 AM To: help-gnu-emacs@gnu.org Subject: Re: Performance problems (CPU 100%) with NULs in files > From: "Ludwig, Mark" > Date: Sat, 24 Sep 2011 00:20:24 +0000 >=20 > What I have found is that the "problem" is due to a "line" of text being = extremely 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 printab= le character and get the same result.) Yes, this is a well-known case that causes the current display engine become very slow. IIRC, it has been like that since Emacs 21.1. > 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. Please file a bug report. It is not unreasonable to expect the code to be optimized in some way to cater to such use cases. And thanks for taking your time to investigate this.