From: David Kastrup <dak@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: Emacs awfully slow on some files
Date: Fri, 14 Aug 2009 10:09:18 +0200 [thread overview]
Message-ID: <87vdkqkea9.fsf@lola.goethe.zz> (raw)
In-Reply-To: 9de1a5ef0908131509j6ba1681ra1357a058d607382@mail.gmail.com
Fabian Ezequiel Gallina <galli.87@gmail.com> writes:
> 2009/8/11 Stefan Monnier <monnier@iro.umontreal.ca>:
>>> 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
next prev parent reply other threads:[~2009-08-14 8:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-10 18:04 Emacs awfully slow on some files Deniz Dogan
2009-08-10 19:01 ` Eli Zaretskii
2009-08-11 15:04 ` Stefan Monnier
2009-08-11 15:34 ` Deniz Dogan
2009-08-13 22:09 ` Fabian Ezequiel Gallina
2009-08-14 8:09 ` David Kastrup [this message]
2009-08-14 8:43 ` Miles Bader
2009-08-14 9:52 ` Eli Zaretskii
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=87vdkqkea9.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).