all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





             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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.