From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs awfully slow on some files Date: Fri, 14 Aug 2009 10:09:18 +0200 Organization: Organization?!? Message-ID: <87vdkqkea9.fsf@lola.goethe.zz> References: <7b501d5c0908101104v6fb4d56axe3f5ea28628d7fe3@mail.gmail.com> <9de1a5ef0908131509j6ba1681ra1357a058d607382@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1250237453 9345 80.91.229.12 (14 Aug 2009 08:10:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Aug 2009 08:10:53 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 14 10:10:46 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mbrrv-0004hc-N6 for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 10:10:36 +0200 Original-Received: from localhost ([127.0.0.1]:39182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbrrv-00038K-2a for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 04:10:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mbrrc-00031Z-LB for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:10:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbrrW-0002zc-As for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:10:16 -0400 Original-Received: from [199.232.76.173] (port=57787 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbrrW-0002zW-7l for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:10:10 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:37385) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MbrrV-0008Cq-Ne for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:10:09 -0400 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbrrT-0007fR-9A for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:10:08 -0400 Original-Received: from root by ciao.gmane.org with local (Exim 4.43) id 1MbrrO-0004PQ-Gm for emacs-devel@gnu.org; Fri, 14 Aug 2009 08:10:02 +0000 Original-Received: from p5b2c270d.dip.t-dialin.net ([91.44.39.13]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Aug 2009 08:10:02 +0000 Original-Received: from dak by p5b2c270d.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Aug 2009 08:10:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5b2c270d.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:p/NeajLcAkXFtL72xo0bLsPH8/M= X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114221 Archived-At: Fabian Ezequiel Gallina writes: > 2009/8/11 Stefan Monnier : >>> I have a file which is 1 MB long and all of the content is on a single >>> line.  Using Emacs on this file is pretty much impossible due to the >>> super-sluggish behavior.  It's embarrassing.  Why is this? >> >> It's probably a combination of various pieces of code which make >> incorrect assumptions about the expected line length. >> >>> Can it be fixed? >> >> Yes. >> >> > > Where should I start looking at in order to try fix this. I really > would like to be able to use Emacs on ugly files too. There is cache-long-line-scans is a variable defined in `C source code'. Its value is nil Automatically becomes buffer-local when set in any fashion. Documentation: Non-nil means that Emacs should use caches to handle long lines more quickly. Normally, the line-motion functions work by scanning the buffer for newlines. Columnar operations (like `move-to-column' and `compute-motion') also work by scanning the buffer, summing character widths as they go. This works well for ordinary text, but if the buffer's lines are very long (say, more than 500 characters), these motion functions will take longer to execute. Emacs may also take longer to update the display. If `cache-long-line-scans' is non-nil, these motion functions cache the results of their scans, and consult the cache to avoid rescanning regions of the buffer until the text is modified. The caches are most beneficial when they prevent the most searching---that is, when the buffer contains long lines and large regions of characters with the same, fixed screen width. When `cache-long-line-scans' is non-nil, processing short lines will become slightly slower (because of the overhead of consulting the cache), and the caches will use memory roughly proportional to the number of newlines and characters whose screen width varies. The caches require no explicit maintenance; their accuracy is maintained internally by the Emacs primitives. Enabling or disabling the cache should not affect the behavior of any of the motion functions; it should only affect their performance. However, this variable has defaulted to nil for quite a long time. I should be surprised if setting it non-nil would not tend to exhibit bugs. -- David Kastrup