From: Achim Gratz <Stromeko@nexgo.de>
To: 45320@debbugs.gnu.org
Subject: bug#45320: 27.1; diff-refine performance regression
Date: Sat, 19 Dec 2020 09:12:52 +0100 [thread overview]
Message-ID: <87a6ua5i4b.fsf@Rainer.invalid> (raw)
In GNU Emacs 27.1 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.24.22, cairo version 1.16.0)
The following change is highly problematic:
--8<---------------cut here---------------start------------->8---
** Diff mode
*** Hunks are now automatically refined by font-lock.
To disable refinement, set the new user option 'diff-refine' to nil.
To get back the old behavior where hunks are refined as you navigate
through a diff, set 'diff-refine' to the symbol 'navigate'.
--8<---------------cut here---------------end--------------->8---
The refinement is run synchronously and can't be interrupted.
The used algorithm clearly has superlinear complexity with the size of
the diff hunk. I frequently use diff-mode for comparison of log files
from compilations, which routinely creates large hunks and sometimes
very large ones. In mild cases that stalls Emacs for a few seconds
upwards to a minute, but I'm encountering larger diff hunks regularly
that do not complete refinement after more than an hour of burning
through 100% CPU (and not a slow one) when I try. Due to the way this
is implemented, the refinement can not be stopped from within Emacs and
stopping it from the outside has a high propensity of killing Emacs and
taking all unsaved work with it.
Auto-refinement of diff hunks should
1. be stopped
a) after a customizable time threshold (personally I'd be OK with
something like 1s, but other folks may have less patience),
b) when the user tries to move point (even small delays are annoying
when you really just want to scroll through the file),
c) when C-g or the corresponding signal is issued.
2. not be attempted at all
a) when the hunk size exceeds a customizable threshold,
b) when the diff in question has run into one of the performance
thresholds multiple times already.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
next reply other threads:[~2020-12-19 8:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-19 8:12 Achim Gratz [this message]
2022-06-07 11:44 ` bug#45320: 27.1; diff-refine performance regression Lars Ingebrigtsen
2022-06-08 6:50 ` Juri Linkov
2022-06-13 15:11 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6ua5i4b.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--cc=45320@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).