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