Re: Performance degradation from long lines

[Ihor Radchenko <yantar92@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4953 bytes --]


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

I would like to point out that the long line problem also exists for
non-file buffers.
Specifically, evaluating debug-on-entry for org-mode buffer parsing
functions often leads to ridiculously long lines (pretty much the whole
buffer is transformed into a single line), which takes forever to
display.
find-file-literally does not help with this problem at all.

Best,
Ihor


Eli Zaretskii <eliz@gnu.org> writes:

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]