[Top][All Lists]

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

Re: Performance degradation from long lines

From: Phil Sainty
Subject: Re: Performance degradation from long lines
Date: Thu, 25 Oct 2018 16:26:53 +1300
User-agent: Orcon Webmail

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

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.


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:


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.


reply via email to

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