bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32728: bug#32729: Xemacs 23 times as fast as GNU Emacs


From: Phil Sainty
Subject: bug#32728: bug#32729: Xemacs 23 times as fast as GNU Emacs
Date: Sun, 13 Oct 2019 23:49:41 +1300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 12/10/19 4:57 PM, Lars Ingebrigtsen wrote:
> (Note: Don't visit the " *zeroes*" buffer after this, because that
> will hang Emacs totally.  I guess the long-line display problem
> hasn't been fixed after all?)

I imagine you're thinking of so-long.el here, in which case there may
be a misconception.  so-long helps tremendously in certain situations,
but it doesn't (and cannot) eliminate all sources of potential
slowness in the face of extremely long lines -- ultimately the C code
still needs time to process the lines being displayed, and so-long.el
can't make that code work any faster.

The biggest problem in this case (by far) is that point has been left
at the end of the line following the insertion, and in order for the
redisplay to *display* the end of the line, it's having to process a
gigabyte of data.  My largest test case for so-long.el was a couple of
orders of magnitude smaller than this, and Emacs wasn't remotely happy
showing the end of that line, let alone this one.

(What so-long is really good at is preventing situations whereby
merely visiting a file -- with point still at the beginning of the
buffer -- caused Emacs to hang badly; which can easily happen when
various modes and options are active.  It can work wonders in those
cases.  If you try to display the end of a really gargantuan line of
data like this, though, you're simply at the mercy of other factors.)

If you added a (goto-char (point-min)) before switching to the
*zeroes* buffer then, given that there's not much else happening in
that buffer which would create issues, Emacs shouldn't hang when you
switch to it.

The further you move into that line, though, the worse the performance
is going to get (so the key take-away here would be to avoid doing that
when dealing with this kind of data, if at all possible).

Also note that `so-long' doesn't actually trigger automatically if you
simply create a buffer and throw a ton of data into it.  The automatic
behaviour is tied to `set-auto-mode' and intended to deal with users
visiting files.  Auto-detecting the sudden insertion of large lines
into an existing buffer is a different kettle of fish, and the current
library does not attempt to cater for it.  So if you wanted to trigger
it in this example you would need to call it explicitly.


-Phil






reply via email to

[Prev in Thread] Current Thread [Next in Thread]