Re: Performance degradation from long lines

[Phil Sainty]

On 2018-10-25 12:59, mithraeum wrote:
> 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.

Broadly speaking, this is what so-long.el is about.  It does not help
with the redisplay code itself, but it disables elisp-visible options
which it considers may affect performance under long-line conditions.

https://savannah.nongnu.org/projects/so-long

The behaviour is automatic in accordance with how the user has
configured the library -- there is no prompting -- but C-c C-c will
revert back to the original mode if that is desired.

As it happens I've been working on this again in recent days, and
intend to release this to GNU ELPA in the near future.  I haven't
finished testing all the new changes, so there may be new bugs, but
the latest work-in-progress code can be found at:

http://git.savannah.nongnu.org/cgit/so-long.git/plain/so-long.el?h=wip

For the example presented at https://emacs.stackexchange.com/q/598,
visiting the file one_line.json hangs Emacs 26.1 for over three
minutes (for me, using emacs -Q), whereas with so-long.el it is usable
almost instantly.  If you actually proceed with editing the file, then
performance still degrades as you get further into that enormous line;
but avoiding that initial hang seems like an obvious win.

If there was some future work on the redisplay to provide a "reduced
display capabilities" option or mode, configuring so-long to enable
that should be trivial.


-Phil