GNU bug report logs - #45320
27.1; diff-refine performance regression

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Achim Gratz <Stromeko@HIDDEN>; dated Sat, 19 Dec 2020 08:14:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.
Removed tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 13 Jun 2022 15:11:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 13 11:11:27 2022
Received: from localhost ([127.0.0.1]:60131 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1o0lix-0001ro-Cn
	for submit <at> debbugs.gnu.org; Mon, 13 Jun 2022 11:11:27 -0400
Received: from lists.gnu.org ([209.51.188.17]:39878)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
 id 1o0liv-0001re-1p
 for submit <at> debbugs.gnu.org; Mon, 13 Jun 2022 11:11:25 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:57718)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
 id 1o0liu-00037f-T7
 for bug-gnu-emacs@HIDDEN; Mon, 13 Jun 2022 11:11:24 -0400
Received: from ciao.gmane.io ([116.202.254.214]:43872)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
 id 1o0lig-0005Lu-OA
 for bug-gnu-emacs@HIDDEN; Mon, 13 Jun 2022 11:11:24 -0400
Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
 id 1o0lie-0000Ln-2g
 for bug-gnu-emacs@HIDDEN; Mon, 13 Jun 2022 17:11:08 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bug-gnu-emacs@HIDDEN
From: Achim Gratz <Stromeko@HIDDEN>
Subject: Re: bug#45320: 27.1; diff-refine performance regression
Date: Mon, 13 Jun 2022 17:11:00 +0200
Organization: Linux Private Site
Message-ID: <87o7ywvbsr.fsf@HIDDEN>
References: <87a6ua5i4b.fsf@HIDDEN> <87h74wk898.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)
Cancel-Lock: sha1:iXXDshjGcTIzFzY5jTE18h2eO+U=
Received-SPF: pass client-ip=116.202.254.214;
 envelope-from=geb-bug-gnu-emacs@HIDDEN; helo=ciao.gmane.io
X-Spam_score_int: -16
X-Spam_score: -1.7
X-Spam_bar: -
X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

Lars Ingebrigtsen writes:
> This isn't the common use case for showing diffs, so it sounds like you
> should just alter the 'diff-refine' user option as described above.

The problem is caused by a change in defaults and whether or not the use
case seems common to you is besides the point.  The default used to be
no refinement and the change in default was done on the assumption that
the performance hit would generally not be bothersome.  As long as (GNU)
grep does have this clearly superlinear complexity characteristic that
simply isn't true (just for entertainment I've let Emacs hang while grep
finishes the refinement several times and it is not uncommon that I see
grep taking several minutes.  I think the longest I've kept it running
was way over one hour.

>> 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.
>
> The problem with  of these is that font-locking is done from
> redisplay, and if you `C-g' something from those functions, it'll just
> try to restart the fontification.  But...  I guess we could slap
> something around `diff--font-lock-refined' to change the value
> (buffer-locally) of diff-refine if the user hits `C-g' while it's
> running?

My go-to solution is to send USR2 to the emacs process, but that's
really not something I should ever need to do with an Emacs in standard
configuration.

>> 2. not be attempted at all
>>
>> a) when the hunk size exceeds a customizable threshold,
>
> That should be possible...

The hunk size only factors into this due to the superlinear complexity in
the refinement.  It might be tricky to figure out a size that works
across all inputs since the structure of the hunk is also important.

>> b) when the diff in question has run into one of the performance
>>    thresholds multiple times already.
>
> I'm not sure that's practical.
>
> Anybody have any other ideas here?

Ideally all such external processes should run asynchronously (as a
"future") with a timeout.  If there is a timeout event, the user presses
C-g or point is moved to a different hunk before the result gets
delivered the process simply gets canceled, otherwise there is another
round of redisplay that is using the result.  I guess that caching previous
results would be quite useful at least in this particular case, so the
details of the implementation could become quite involved.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45320; Package emacs. Full text available.

Message received at 45320 <at> debbugs.gnu.org:


Received: (at 45320) by debbugs.gnu.org; 8 Jun 2022 06:52:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 08 02:52:08 2022
Received: from localhost ([127.0.0.1]:42276 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nypY0-0003ic-H2
	for submit <at> debbugs.gnu.org; Wed, 08 Jun 2022 02:52:08 -0400
Received: from relay9-d.mail.gandi.net ([217.70.183.199]:44489)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1nypXy-0003i5-J5
 for 45320 <at> debbugs.gnu.org; Wed, 08 Jun 2022 02:52:07 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by mail.gandi.net (Postfix) with ESMTPSA id 3C1C3FF804;
 Wed,  8 Jun 2022 06:51:58 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: Re: bug#45320: 27.1; diff-refine performance regression
Organization: LINKOV.NET
References: <87a6ua5i4b.fsf@HIDDEN> <87h74wk898.fsf@HIDDEN>
Date: Wed, 08 Jun 2022 09:50:46 +0300
In-Reply-To: <87h74wk898.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Tue,
 07 Jun 2022 13:44:51 +0200")
Message-ID: <86h74vmywp.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 45320
Cc: 45320 <at> debbugs.gnu.org, Achim Gratz <Stromeko@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> 2. not be attempted at all
>>
>> a) when the hunk size exceeds a customizable threshold,
>
> That should be possible...

This looks like the recently added outline-default-rules
(that also can be used for diff-mode outlines, but not for diff-refine)
with such possible values:

  - `subtree-has-long-lines' to only show the heading branches when
    long lines are detected in its subtree (see
    `outline-default-long-line' for the definition of long lines).

  - `subtree-is-long' to only show the heading branches when its
    subtree contains more than `outline-default-line-count' lines.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45320; Package emacs. Full text available.
Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 45320 <at> debbugs.gnu.org:


Received: (at 45320) by debbugs.gnu.org; 7 Jun 2022 11:45:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 07 07:45:04 2022
Received: from localhost ([127.0.0.1]:38802 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nyXdw-0000Oi-69
	for submit <at> debbugs.gnu.org; Tue, 07 Jun 2022 07:45:04 -0400
Received: from quimby.gnus.org ([95.216.78.240]:52366)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1nyXdu-0000Lf-I5
 for 45320 <at> debbugs.gnu.org; Tue, 07 Jun 2022 07:45:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=e7IoLTgZA0vIrEEZtFSbLyImVZ1m+FdN5RHkZC3TUeM=; b=up169ao6qJ2U9hD4URKAUpnKwW
 n5amEhNjKM0e46oOO0I4Q0+pNYOI0K+a5jyCwZ0bQzdBNawPuFyxu2+ZmRBuBLSkL55o9cUHVCxhR
 HGDWXLfni0bD/fFEYJlcvmwH8inxKS3FLbKrqrrY8k/o6MPatJcwl6kyborcBkkviX6c=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1nyXdl-00023C-Kb; Tue, 07 Jun 2022 13:44:56 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Achim Gratz <Stromeko@HIDDEN>
Subject: Re: bug#45320: 27.1; diff-refine performance regression
References: <87a6ua5i4b.fsf@HIDDEN>
X-Now-Playing: Blaine L. Reininger's _Commissions 2 (2)_: "Stellar Violas"
Date: Tue, 07 Jun 2022 13:44:51 +0200
In-Reply-To: <87a6ua5i4b.fsf@HIDDEN> (Achim Gratz's message of "Sat,
 19 Dec 2020 09:12:52 +0100")
Message-ID: <87h74wk898.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Achim Gratz <Stromeko@HIDDEN> writes: > *** 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 > [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 45320
Cc: 45320 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Achim Gratz <Stromeko@HIDDEN> writes:

> *** 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'.
>
> 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.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This isn't the common use case for showing diffs, so it sounds like you
should just alter the 'diff-refine' user option as described above.

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

The problem with  of these is that font-locking is done from
redisplay, and if you `C-g' something from those functions, it'll just
try to restart the fontification.  But...  I guess we could slap
something around `diff--font-lock-refined' to change the value
(buffer-locally) of diff-refine if the user hits `C-g' while it's
running?

> 2. not be attempted at all
>
> a) when the hunk size exceeds a customizable threshold,

That should be possible...

> b) when the diff in question has run into one of the performance
>    thresholds multiple times already.

I'm not sure that's practical.

Anybody have any other ideas here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#45320; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 19 Dec 2020 08:13:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 19 03:13:11 2020
Received: from localhost ([127.0.0.1]:40777 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kqXMV-0004Sc-F1
	for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 03:13:11 -0500
Received: from lists.gnu.org ([209.51.188.17]:36480)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Stromeko@HIDDEN>) id 1kqXMU-0004SU-0C
 for submit <at> debbugs.gnu.org; Sat, 19 Dec 2020 03:13:10 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:58710)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <Stromeko@HIDDEN>) id 1kqXMT-0005GX-Re
 for bug-gnu-emacs@HIDDEN; Sat, 19 Dec 2020 03:13:09 -0500
Received: from smtpout2.vodafonemail.de ([145.253.239.133]:58878)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <Stromeko@HIDDEN>) id 1kqXMR-0004wa-3K
 for bug-gnu-emacs@HIDDEN; Sat, 19 Dec 2020 03:13:09 -0500
Received: from smtp.vodafone.de (unknown [10.2.0.33])
 by smtpout2.vodafonemail.de (Postfix) with ESMTP id 1A6D51231B6
 for <bug-gnu-emacs@HIDDEN>; Sat, 19 Dec 2020 09:12:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de;
 s=vfde-smtpout-mb-15sep; t=1608365579;
 bh=KRKpE1mP67MYaWRcVPJTqwAdDC6UlYwL1kFPIsV3QZg=;
 h=From:To:Subject:Date;
 b=M6rgfyMy/QaB8PC2UbxwBgbsSJlDBS1mVeA2GEkF19al9xtJ00URr5hF+s2f2MU8s
 pBKNP86pWqhuRv4fPQVLgq1xUXe3WUHI8Ka8b0J72XKONwyFjFyHLLRiRkFGDYRcSI
 Ok5kcE1kWfMu3HcQHDAJaAx8Ye32E0RIpc5zbhJg=
Received: from Gertrud (p54a0ca05.dip0.t-ipconnect.de [84.160.202.5])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by smtp.vodafone.de (Postfix) with ESMTPSA id A2EA114258A
 for <bug-gnu-emacs@HIDDEN>; Sat, 19 Dec 2020 08:12:58 +0000 (UTC)
From: Achim Gratz <Stromeko@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 27.1; diff-refine performance regression
Date: Sat, 19 Dec 2020 09:12:52 +0100
Message-ID: <87a6ua5i4b.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: This mail is considered clean (visit http://www.eleven.de for
 further information)
X-purgate: clean
X-purgate-size: 2068
X-purgate-ID: 155817::1608365578-000007FA-2097C69F/0/0
Received-SPF: pass client-ip=145.253.239.133; envelope-from=Stromeko@HIDDEN;
 helo=smtpout2.vodafonemail.de
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)


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




Acknowledgement sent to Achim Gratz <Stromeko@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#45320; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Tue, 12 Jul 2022 14:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.