Emacs awfully slow on some files

Emacs awfully slow on some files

[Deniz Dogan]

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? Can it be
fixed? This is with fundamental-mode, by the way. `forward-char' and
`backward-char' are pretty much the only usable commands, even "C-h f"
(describe-function) is extremely slow in this scenario.

-- 
Deniz Dogan

Re: Emacs awfully slow on some files

[Eli Zaretskii]

> Date: Mon, 10 Aug 2009 20:04:08 +0200
> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> 
> 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? Can it be
> fixed?

IIRC, this is a fundamental limitation of the current implementation
of the Emacs display engine.  Too long lines make it very slow.

Does it help to set truncate-lines to a non-nil value?

Re: Emacs awfully slow on some files

[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.

> This is with fundamental-mode, by the way.

Good: in several other modes, I could argue that such a long line is
a bug, but fundamental-mode should cater to weird files.

> `forward-char' and `backward-char' are pretty much the only usable
> commands, even "C-h f" (describe-function) is extremely slow in
> this scenario.

Please report a bug for it via M-x report-emacs-bug, and ideally include
some recipe (in case it depends on the actual content of the long line,
for example, or if it needs more than "emacs -Q" to reproduce).


        Stefan

Re: Emacs awfully slow on some files

[Deniz Dogan]

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.
>
>> This is with fundamental-mode, by the way.
>
> Good: in several other modes, I could argue that such a long line is
> a bug, but fundamental-mode should cater to weird files.
>
>> `forward-char' and `backward-char' are pretty much the only usable
>> commands, even "C-h f" (describe-function) is extremely slow in
>> this scenario.
>
> Please report a bug for it via M-x report-emacs-bug, and ideally include
> some recipe (in case it depends on the actual content of the long line,
> for example, or if it needs more than "emacs -Q" to reproduce).
>

Done. I copied the contents of the bug report buffer and used the
Gmail web interface to post it. I hope it doesn't matter.

-- 
Deniz Dogan

Re: Emacs awfully slow on some files

[Fabian Ezequiel Gallina]

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.

>> This is with fundamental-mode, by the way.
>
> Good: in several other modes, I could argue that such a long line is
> a bug, but fundamental-mode should cater to weird files.
>

Actually today I was editing to an SQL file which had really long
lines and was slow as hell, there are several modes that should
support very long lines without making Emacs that slow not only
fundamental-mode.

I guess this should be a priority thing to fix, I'll try to see if I
can find some solution, unfortunately my C knowledge is not that good
and I'm new to Emacs Lisp but I will give it a try and let you know if
I can do some enhancement.

>
>> `forward-char' and `backward-char' are pretty much the only usable
>> commands, even "C-h f" (describe-function) is extremely slow in
>> this scenario.
>
> Please report a bug for it via M-x report-emacs-bug, and ideally include
> some recipe (in case it depends on the actual content of the long line,
> for example, or if it needs more than "emacs -Q" to reproduce).
>
>
>        Stefan
>



Best Regards,
-- 
Fabián E. Gallina

Re: Emacs awfully slow on some files

[David Kastrup]

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

Re: Emacs awfully slow on some files

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
>     cache-long-line-scans is a variable defined in `C source code'.
>     Its value is nil
...
> 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.

I tried it last year sometime; emacs crashed quite quickly...

-Miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Emacs awfully slow on some files

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Fri, 14 Aug 2009 17:43:11 +0900
> Cc: emacs-devel@gnu.org
> 
> David Kastrup <dak@gnu.org> writes:
> >     cache-long-line-scans is a variable defined in `C source code'.
> >     Its value is nil
> ...
> > 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.
> 
> I tried it last year sometime; emacs crashed quite quickly...

A bug report is in order, IMO.