GNU bug report logs - #80438
31.0.50; Slow handling of `modification-hooks` in `erase-buffer`

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: Stefan Monnier <monnier@HIDDEN>; dated Wed, 18 Feb 2026 20:45:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

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


Received: (at 80438) by debbugs.gnu.org; 19 Feb 2026 13:33:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 19 08:33:06 2026
Received: from localhost ([127.0.0.1]:50910 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1vt49S-00016b-9q
	for submit <at> debbugs.gnu.org; Thu, 19 Feb 2026 08:33:06 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14619)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
 id 1vt49P-00015z-CG
 for 80438 <at> debbugs.gnu.org; Thu, 19 Feb 2026 08:33:04 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F24FC81C9A;
 Thu, 19 Feb 2026 08:32:56 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1771507976;
 bh=GGI6sE1HbvYyv84Tktlu94fBQzouehUbwzPjLfGK5ok=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=DSvUkNDtHn3xZmDaybwAYLHEbCZFo7snaUKQsTnnlvethQHT3bOMyBkIffLkj4KVw
 NlCjMN7xebzVIelfAGGHNg4B3KCGCyEAvRL6M6BG9pXdTUThnq9B76GZi/qVgKFtIT
 l9Au3U+7JsFe8gtUnbkBE+Jw9t99tDoVpfSQgYVj3bEBcFoxv5y4YhrzXJ5kSrx2HN
 J41FA7UcSAjlcej/Qkv/veKruqDRy2UbUPfuk7hNDTEdxU1qVBqoCdSTLa1S1jhhZJ
 jV0sh4I2AIUu6jSF6c6vRgKms1ODQeOdZyhDzYhzaWhMz/5M/9RRaz+J1/opV1CiBH
 f+e9iKC8O3gPQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0060A8085E;
 Thu, 19 Feb 2026 08:32:55 -0500 (EST)
Received: from pastel (104-195-243-38.cpe.teksavvy.com [104.195.243.38])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B3FFD1203FF;
 Thu, 19 Feb 2026 08:32:55 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#80438: 31.0.50; Slow handling of `modification-hooks` in
 `erase-buffer`
In-Reply-To: <87342x2q6j.fsf@HIDDEN>
Message-ID: <jwvms14j202.fsf-monnier+Inbox@HIDDEN>
References: <jwvzf55by1v.fsf-monnier+@gnu.org> <87342x2q6j.fsf@HIDDEN>
Date: Thu, 19 Feb 2026 08:32:53 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.148 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -1.5 (-)
X-Debbugs-Envelope-To: 80438
Cc: 80438 <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 (---)

>> If you read your email with Gnus and step through message with large
>> diff attachments, you may have noticed that it can take a long time to
>> display those messages.  This is normal (tho clearly undesirable)
>> because Gnus first uses `font-lock-ensure` in an auxiliary buffer
>> containing the attachment and then copies the result to the article
>> buffer, and font-locking tends of thousands of lines of diff can take
>> a while.  We "know" how to fix to make use of `jit-lock`, tho noone has
>> stepped up yet to do the footwork, AFAIK.
> Maybe because doing this is not as simple as just replacing the calls
> with `jit-lock-register` and `jit-lock-bounds`?

Definitely.  If it was that simple I'd have done it already.

>> So, those tens of seconds are spent mostly inside `erase-buffer`.
>> I suspect it's linked to the `diff--overlay-auto-delete` hook placed on
>> a `modification-hooks` overlay property, tho most of the time is still
>> spent in `erase-buffer` itself rather than running this hook.
>>
>> I haven't investigated much further yet.  My crystal ball says that it's
>> probably spending a lot of time wading through all those overlays,
>> deciding which ones have `modification-hooks` and which ones don't and
>> in which order to run them or something.  Tho maybe the
>> `modification-hooks` thingy is a red-herring and the problem is just the
>> sheer number of overlays generated by `diff-refine`.
> `gnus-summary-display-article` could explicitly delete all overlays
> before calling `erase-buffer`.

Maybe that would be an OK workaround.  Tho maybe it would take just as
long (or even longer).  I'd like to understand better why it takes so
much time in the first place.


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

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


Received: (at 80438) by debbugs.gnu.org; 19 Feb 2026 07:22:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 19 02:22:06 2026
Received: from localhost ([127.0.0.1]:47205 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1vsyMP-0000vJ-Ex
	for submit <at> debbugs.gnu.org; Thu, 19 Feb 2026 02:22:06 -0500
Received: from mout-p-202.mailbox.org ([80.241.56.172]:39016)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vsyLu-0000tr-CG
 for 80438 <at> debbugs.gnu.org; Thu, 19 Feb 2026 02:21:35 -0500
Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4fGlDQ3Dmnz9tSq;
 Thu, 19 Feb 2026 08:21:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; 
 t=1771485686;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=bS1iSFrpZTUwjpRpYH2aE1Jm9P2MP0oY5j/Yd9Owdpk=;
 b=OYcM0MHRShygZlyybEH0nE13dOlG9+VgOxbHDwaLyctHwyM3AROx8pRP/aCZ2GSUTarFAa
 2r9iApafANlIM1l7uTQpErv9ade93o52TNKhjokwMklfrM82rTQdDQ6DO5EDVKWfNej+Oa
 p6zZaHWI398hA5/sH4mlmUmKBVPmPRoYVYFTNDPdG8xlWvGpsubA/Dy4AV9GZnU3ElHN21
 XqFusRKsj6S7aBQRMIrnuO1xrRUW55ScTeNsV/i6GGLWLU9rS/HuY89eb1nMajrMi9IsOT
 bS7yo90PwQcJR2MjZaLlrFjDLElfaTuI08AvauA82NVsQC/BKG4/v4PNSwnbFQ==
From: Juri Linkov <juri@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#80438: 31.0.50; Slow handling of `modification-hooks` in
 `erase-buffer`
In-Reply-To: <jwvzf55by1v.fsf-monnier+@gnu.org>
Organization: LINKOV.NET
References: <jwvzf55by1v.fsf-monnier+@gnu.org>
Date: Thu, 19 Feb 2026 09:18:44 +0200
Message-ID: <87342x2q6j.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 80438
Cc: 80438 <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: -1.7 (-)

> If you read your email with Gnus and step through message with large
> diff attachments, you may have noticed that it can take a long time to
> display those messages.  This is normal (tho clearly undesirable)
> because Gnus first uses `font-lock-ensure` in an auxiliary buffer
> containing the attachment and then copies the result to the article
> buffer, and font-locking tends of thousands of lines of diff can take
> a while.  We "know" how to fix to make use of `jit-lock`, tho noone has
> stepped up yet to do the footwork, AFAIK.

Maybe because doing this is not as simple as just replacing the calls
with `jit-lock-register` and `jit-lock-bounds`?

> So, those tens of seconds are spent mostly inside `erase-buffer`.
> I suspect it's linked to the `diff--overlay-auto-delete` hook placed on
> a `modification-hooks` overlay property, tho most of the time is still
> spent in `erase-buffer` itself rather than running this hook.
>
> I haven't investigated much further yet.  My crystal ball says that it's
> probably spending a lot of time wading through all those overlays,
> deciding which ones have `modification-hooks` and which ones don't and
> in which order to run them or something.  Tho maybe the
> `modification-hooks` thingy is a red-herring and the problem is just the
> sheer number of overlays generated by `diff-refine`.

`gnus-summary-display-article` could explicitly delete all overlays
before calling `erase-buffer`.
Information forwarded to bug-gnu-emacs@HIDDEN:
bug#80438; Package emacs. Full text available.

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


Received: (at submit) by debbugs.gnu.org; 18 Feb 2026 20:44:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 18 15:44:06 2026
Received: from localhost ([127.0.0.1]:41161 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1vsoP0-00032f-Ho
	for submit <at> debbugs.gnu.org; Wed, 18 Feb 2026 15:44:06 -0500
Received: from lists.gnu.org ([2001:470:142::17]:53982)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
 id 1vsoOy-00031z-0B
 for submit <at> debbugs.gnu.org; Wed, 18 Feb 2026 15:44:04 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
 id 1vsoOr-0007Aj-Sb
 for bug-gnu-emacs@HIDDEN; Wed, 18 Feb 2026 15:43:58 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
 id 1vsoOq-0004VQ-5f
 for bug-gnu-emacs@HIDDEN; Wed, 18 Feb 2026 15:43:57 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8CE5E80329;
 Wed, 18 Feb 2026 15:43:54 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1771447433;
 bh=9gHOLyCF/ds/PYjitzG/iywMOpg7C+zr4FeOIL0VXss=;
 h=From:To:Subject:Date:From;
 b=EzxTiRvUKCIZ0bwgfjjLWd7pOnL/rNOELTRXm0DOdfB2CNExLl7xwtQUoRJuvpEQ+
 NrngybgkktbGk4h6cPeSALq5ILGZl5svbRgekGEJ0XGgsfP8hTjM338zABZEbgYk3N
 8iWzMTew8YGIDBhWmK9Z1XfteZoiDHl3ZqR+wJDO4FZPfRp9ObP+PV5csfTG3rOzqg
 R5al8dSNUL8LNqrRiGxikAYrj0aCm+Yx0lwK2qwolSPFhxzE66qIgirIZK292THEat
 GyFAWqCoPbetT8SQHZDxOuM3PVtZpCSgnVuTgvEmuB3emK/8F8n4BjGQdoh+DoLfPX
 p+dpC4hrCIPZw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A99BF81B33;
 Wed, 18 Feb 2026 15:43:53 -0500 (EST)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9973C1208C9;
 Wed, 18 Feb 2026 15:43:53 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; Slow handling of `modification-hooks` in `erase-buffer`
Message-ID: <jwvzf55by1v.fsf-monnier+@gnu.org>
X-Debbugs-Cc: monnier@HIDDEN
Date: Wed, 18 Feb 2026 15:43:50 -0500
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.164 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
Received-SPF: pass client-ip=132.204.25.50;
 envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.0 (/)
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: -1.0 (-)

Package: Emacs
Version: 31.0.50

If you read your email with Gnus and step through message with large
diff attachments, you may have noticed that it can take a long time to
display those messages.  This is normal (tho clearly undesirable)
because Gnus first uses `font-lock-ensure` in an auxiliary buffer
containing the attachment and then copies the result to the article
buffer, and font-locking tends of thousands of lines of diff can take
a while.  We "know" how to fix to make use of `jit-lock`, tho noone has
stepped up yet to do the footwork, AFAIK.

What is more surprising is that moving *from* such a message to another
one can also take a long time (less long, admittedly, but can still
easily be tens of seconds).  I tried it with a 27K lines diff from
"master 5be60a2003a: ; Update ldefs-boot.el", where moving to the next
message (a small message normally displayed "instantaneously") took 30s.
`profiler-report` says:

       37518 100% - command-execute
       37518 100%  - call-interactively
       37518 100%   - funcall-interactively
       37518 100%    - eval-expression
       37518 100%     - handler-bind-1
       37518 100%      - #<byte-code-function 269>
       37518 100%       - #<byte-code-function 5CC>
       37518 100%        - eval
       37518 100%         - progn
       37518 100%          - call-interactively
       37518 100%           - funcall-interactively
       37518 100%            - gnus-summary-scroll-up
       37514  99%             - gnus-summary-select-article
       37514  99%              - gnus-summary-display-article
       37338  99%               - erase-buffer
        8762  23%                - diff--overlay-auto-delete
        8762  23%                   delete-overlay
         172   0%               - gnus-article-prepare
       [...]

So, those tens of seconds are spent mostly inside `erase-buffer`.
I suspect it's linked to the `diff--overlay-auto-delete` hook placed on
a `modification-hooks` overlay property, tho most of the time is still
spent in `erase-buffer` itself rather than running this hook.

I haven't investigated much further yet.  My crystal ball says that it's
probably spending a lot of time wading through all those overlays,
deciding which ones have `modification-hooks` and which ones don't and
in which order to run them or something.  Tho maybe the
`modification-hooks` thingy is a red-herring and the problem is just the
sheer number of overlays generated by `diff-refine`.


=== Stefan
Acknowledgement sent to Stefan Monnier <monnier@HIDDEN>:
New bug report received and forwarded. Copy sent to monnier@HIDDEN, bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to monnier@HIDDEN, bug-gnu-emacs@HIDDEN:
bug#80438; 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: Thu, 19 Feb 2026 13:45:02 UTC

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