Re: Performance degradation from long lines

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 24 Oct 2018 23:59:02 +0000
> From: mithraeum <mithraeum@protonmail.com>
> 
> In the case of gui Emacs, the reduction of display capability is real,
> but it seems prefereable to freezing Emacs or slowing it down to a crawl.

It is only preferable if the resulting display will be acceptable by
enough users to justify the costs of developing and maintaining the
separate "simplified" display code.

> It also seems better than, or at least a viable alternative to, opening
> files with M-x find-file-literally, which loses font-lock and leaves
> the buffer stuck in Fundamental mode.

Again, only if the result of the "simplified" display will be more
acceptable than Fundamental mode by enough users.  The significant
advantage of find-file-literally is that it already exists, and so
incurs exactly zero costs.

> In the r/emacs thread I was encouraged to post to emacs-dev to get
> the input of more developers, so here I am.

The main motivation for my request to start a discussion here was to
find out whether such a "simplified" display will be acceptable on GUI
frames by enough users.  In r/emacs thread, I described some features
that will be lost (I can repeat here if people prefer that); please
consult that if you want to make up your mind and provide opinions.
IMO, the costs for developing and maintaining such a "simplified"
display code will only be justified if enough people will consider the
resulting display both acceptable and significantly preferable to what
find-file-literally already provides.

> First is that Emacs could have a user-configurable timeout after which
> it could warn the user that it's taking an unexpectedly long time to
> open a file (or find the end of a line) and ask whether to abort,
> continue trying, or drop down to a mode with reduced display
> capabilities (which could be either the equivalent of
> find-file-literally or the above simplified display techniques, if
> they're implemented).

First, it isn't visiting the file (i.e. reading it into a buffer) that
takes time; in fact, the time to visit is almost entirely unaffected
by line length.  What takes time is the display of the initial
windowful of the file's text (and following redisplay as result of
editing).  So I guess the proposal is to have a time-out on that
initial display and on redisplay cycles.

Second, I'm not sure we need to measure the time; line length is a
reliable enough indication of expected display slowdown, so we could
simply look at the typical line lengths instead, which is much
simpler to implement.

And third, it seems like so-long mode already implements this idea, so
perhaps we should simply add it to the core and integrate it by
default.

> The second idea is to use to ignore anything that would slow Emacs
> down while doing a simple count of the line length, and if the line
> length so far is over a certain threshold to ask the same questions as
> above about aborting, continuing, or dropping down to a fail-safe
> mode.

See above.

Please note that these ideas are a kind of "band-aid": they don't
solve the root causes for the slow display, they just disable some
features which make that slow display even slower, and by that make
the critical line length larger.  But you can still create a file with
lines so long that even in Fundamental mode it will be painfully slow
to move through and edit.

> The third is to use some of Emacs' new async abilities to try to open
> the file.  It might still take forever to open, but at least it shouldn't
> freeze all of Emacs in the meantime.

There are no such abilities; the concurrency features in Emacs 26
don't allow running the display code in a separate thread.  Emacs Lisp
threads are mostly cooperative, and only one thread is allowed to run
at any given time.  And the current design of Emacs is such that
redisplay must run from a Lisp thread.