GNU bug report logs - #79021
31.0.50; Unnecessary GC in after-load-functions

Previous Next

Package: emacs;

Reported by: Helmut Eller <eller.helmut <at> gmail.com>

Date: Mon, 14 Jul 2025 20:05:02 UTC

Severity: normal

Found in version 31.0.50

To reply to this bug, email your comments to 79021 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Mon, 14 Jul 2025 20:05:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Helmut Eller <eller.helmut <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 14 Jul 2025 20:05:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Unnecessary GC in after-load-functions
Date: Mon, 14 Jul 2025 22:04:18 +0200
In loadup.el there is this:

  (add-hook 'after-load-functions (lambda (_) (garbage-collect)))

What's this for?  It seems unnecessary.

It would be nice to remove this, because without it the time to execute
loadup.el goes down from 13 seconds to 6.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Tue, 15 Jul 2025 02:31:02 GMT) Full text and rfc822 format available.

Message #8 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79021 <at> debbugs.gnu.org
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Tue, 15 Jul 2025 05:30:40 +0300
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Mon, 14 Jul 2025 22:04:18 +0200
> 
> In loadup.el there is this:
> 
>   (add-hook 'after-load-functions (lambda (_) (garbage-collect)))
> 
> What's this for?  It seems unnecessary.
> 
> It would be nice to remove this, because without it the time to execute
> loadup.el goes down from 13 seconds to 6.

I presume this is because we don't want to dump any garbage.

Stefan?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Tue, 15 Jul 2025 14:00:02 GMT) Full text and rfc822 format available.

Message #11 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79021 <at> debbugs.gnu.org, Helmut Eller <eller.helmut <at> gmail.com>
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Tue, 15 Jul 2025 09:59:38 -0400
>> In loadup.el there is this:
>> 
>>   (add-hook 'after-load-functions (lambda (_) (garbage-collect)))
>> 
>> What's this for?  It seems unnecessary.
>> 
>> It would be nice to remove this, because without it the time to execute
>> loadup.el goes down from 13 seconds to 6.
>
> I presume this is because we don't want to dump any garbage.
> Stefan?

AFAIK it was added to keep the dumped Emacs' heap "dense": if we run the
GC only "in the normal way", the heap objects created during `loadup.el`
end up interspersed with more free spaces.

It's possible/likely that the portable dumper has made that unnecessary.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Fri, 12 Sep 2025 07:27:02 GMT) Full text and rfc822 format available.

Message #14 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79021 <at> debbugs.gnu.org
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Fri, 12 Sep 2025 09:26:02 +0200
[Message part 1 (text/plain, inline)]
On Tue, Jul 15 2025, Stefan Monnier wrote:

>>> In loadup.el there is this:
>>> 
>>>   (add-hook 'after-load-functions (lambda (_) (garbage-collect)))
>>> 
>>> What's this for?  It seems unnecessary.
>>> 
>>> It would be nice to remove this, because without it the time to execute
>>> loadup.el goes down from 13 seconds to 6.
>>
>> I presume this is because we don't want to dump any garbage.
>> Stefan?
>
> AFAIK it was added to keep the dumped Emacs' heap "dense": if we run the
> GC only "in the normal way", the heap objects created during `loadup.el`
> end up interspersed with more free spaces.
>
> It's possible/likely that the portable dumper has made that unnecessary.

Should I commit this?

[loadup.patch (text/x-diff, inline)]
diff --git a/lisp/loadup.el b/lisp/loadup.el
index 18f09878f98..05bd468b713 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -127,7 +127,11 @@
 
 ;; Do it after subr, since both after-load-functions and add-hook are
 ;; implemented in subr.el.
-(add-hook 'after-load-functions (lambda (_) (garbage-collect)))
+;;
+;; This was probably done to reduce fragmentation with unexec.  With the
+;; pdumper it makes little sense.  See bug#79021.
+(if (not (fboundp 'dump-emacs-portable))
+    (add-hook 'after-load-functions (lambda (_) (garbage-collect))))
 
 (load "version")
 

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Fri, 12 Sep 2025 07:56:02 GMT) Full text and rfc822 format available.

Message #17 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>,
 Daniel Colascione <dancol <at> dancol.org>
Cc: 79021 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Fri, 12 Sep 2025 10:54:42 +0300
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  79021 <at> debbugs.gnu.org
> Date: Fri, 12 Sep 2025 09:26:02 +0200
> 
> On Tue, Jul 15 2025, Stefan Monnier wrote:
> 
> >>> In loadup.el there is this:
> >>> 
> >>>   (add-hook 'after-load-functions (lambda (_) (garbage-collect)))
> >>> 
> >>> What's this for?  It seems unnecessary.
> >>> 
> >>> It would be nice to remove this, because without it the time to execute
> >>> loadup.el goes down from 13 seconds to 6.
> >>
> >> I presume this is because we don't want to dump any garbage.
> >> Stefan?
> >
> > AFAIK it was added to keep the dumped Emacs' heap "dense": if we run the
> > GC only "in the normal way", the heap objects created during `loadup.el`
> > end up interspersed with more free spaces.
> >
> > It's possible/likely that the portable dumper has made that unnecessary.
> 
> diff --git a/lisp/loadup.el b/lisp/loadup.el
> index 18f09878f98..05bd468b713 100644
> --- a/lisp/loadup.el
> +++ b/lisp/loadup.el
> @@ -127,7 +127,11 @@
>  
>  ;; Do it after subr, since both after-load-functions and add-hook are
>  ;; implemented in subr.el.
> -(add-hook 'after-load-functions (lambda (_) (garbage-collect)))
> +;;
> +;; This was probably done to reduce fragmentation with unexec.  With the
> +;; pdumper it makes little sense.  See bug#79021.
> +(if (not (fboundp 'dump-emacs-portable))
> +    (add-hook 'after-load-functions (lambda (_) (garbage-collect))))

Are we sure the problem no longer happens with pdumper?  Daniel, WDYT?

In any case, the fboundp test is not enough, we should test the value
of dump-mode instead, I think.  Because Emacs might be built with
pdumper support, but this session is not going to call
dump-emacs-portable, due to command-line options or some other trick.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Fri, 12 Sep 2025 08:03:01 GMT) Full text and rfc822 format available.

Message #20 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>, Helmut Eller <eller.helmut <at> gmail.com>
Cc: 79021 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Fri, 12 Sep 2025 01:01:52 -0700
On September 12, 2025 12:54:42 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Helmut Eller <eller.helmut <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  79021 <at> debbugs.gnu.org
>> Date: Fri, 12 Sep 2025 09:26:02 +0200
>> 
>> On Tue, Jul 15 2025, Stefan Monnier wrote:
>> 
>> >>> In loadup.el there is this:
>> >>> 
>> >>>   (add-hook 'after-load-functions (lambda (_) (garbage-collect)))
>> >>> 
>> >>> What's this for?  It seems unnecessary.
>> >>> 
>> >>> It would be nice to remove this, because without it the time to execute
>> >>> loadup.el goes down from 13 seconds to 6.
>> >>
>> >> I presume this is because we don't want to dump any garbage.
>> >> Stefan?
>> >
>> > AFAIK it was added to keep the dumped Emacs' heap "dense": if we run the
>> > GC only "in the normal way", the heap objects created during `loadup.el`
>> > end up interspersed with more free spaces.
>> >
>> > It's possible/likely that the portable dumper has made that unnecessary.
>> 
>> diff --git a/lisp/loadup.el b/lisp/loadup.el
>> index 18f09878f98..05bd468b713 100644
>> --- a/lisp/loadup.el
>> +++ b/lisp/loadup.el
>> @@ -127,7 +127,11 @@
>>  
>>  ;; Do it after subr, since both after-load-functions and add-hook are
>>  ;; implemented in subr.el.
>> -(add-hook 'after-load-functions (lambda (_) (garbage-collect)))
>> +;;
>> +;; This was probably done to reduce fragmentation with unexec.  With the
>> +;; pdumper it makes little sense.  See bug#79021.
>> +(if (not (fboundp 'dump-emacs-portable))
>> +    (add-hook 'after-load-functions (lambda (_) (garbage-collect))))
>
>Are we sure the problem no longer happens with pdumper?  Daniel, WDYT?
>

It's unnecessary with pdumper, which compacts automatically.

>In any case, the fboundp test is not enough, we should test the value
>of dump-mode instead, I think.  Because Emacs might be built with
>pdumper support, but this session is not going to call
>dump-emacs-portable, due to command-line options or some other trick.

Just delete it.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Fri, 12 Sep 2025 10:40:01 GMT) Full text and rfc822 format available.

Message #23 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 79021 <at> debbugs.gnu.org, eller.helmut <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Fri, 12 Sep 2025 13:39:39 +0300
> Date: Fri, 12 Sep 2025 01:01:52 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: monnier <at> iro.umontreal.ca, 79021 <at> debbugs.gnu.org
> 
> >> -(add-hook 'after-load-functions (lambda (_) (garbage-collect)))
> >> +;;
> >> +;; This was probably done to reduce fragmentation with unexec.  With the
> >> +;; pdumper it makes little sense.  See bug#79021.
> >> +(if (not (fboundp 'dump-emacs-portable))
> >> +    (add-hook 'after-load-functions (lambda (_) (garbage-collect))))
> >
> >Are we sure the problem no longer happens with pdumper?  Daniel, WDYT?
> >
> 
> It's unnecessary with pdumper, which compacts automatically.

Thanks.

> >In any case, the fboundp test is not enough, we should test the value
> >of dump-mode instead, I think.  Because Emacs might be built with
> >pdumper support, but this session is not going to call
> >dump-emacs-portable, due to command-line options or some other trick.
> 
> Just delete it.

It's still useful if starting undumped Emacs, no?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Fri, 12 Sep 2025 11:01:01 GMT) Full text and rfc822 format available.

Message #26 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79021 <at> debbugs.gnu.org, eller.helmut <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Fri, 12 Sep 2025 04:00:35 -0700
On September 12, 2025 3:39:39 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 12 Sep 2025 01:01:52 -0700
>> From: Daniel Colascione <dancol <at> dancol.org>
>> CC: monnier <at> iro.umontreal.ca, 79021 <at> debbugs.gnu.org
>> 
>> >> -(add-hook 'after-load-functions (lambda (_) (garbage-collect)))
>> >> +;;
>> >> +;; This was probably done to reduce fragmentation with unexec.  With the
>> >> +;; pdumper it makes little sense.  See bug#79021.
>> >> +(if (not (fboundp 'dump-emacs-portable))
>> >> +    (add-hook 'after-load-functions (lambda (_) (garbage-collect))))
>> >
>> >Are we sure the problem no longer happens with pdumper?  Daniel, WDYT?
>> >
>> 
>> It's unnecessary with pdumper, which compacts automatically.
>
>Thanks.
>
>> >In any case, the fboundp test is not enough, we should test the value
>> >of dump-mode instead, I think.  Because Emacs might be built with
>> >pdumper support, but this session is not going to call
>> >dump-emacs-portable, due to command-line options or some other trick.
>> 
>> Just delete it.
>
>It's still useful if starting undumped Emacs, no?

I don't think so. It wouldn't be any more useful than it would be in regular Emacs: GC doesn't differ between a dumped and an undumped Emacs, meaning the code above would be good in both or neither. Since we don't have a theory of why it would be useful in any circumstance post-unexec and have data showing it's a pessimization, let's just delete it and take the complexity reduction win.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Fri, 12 Sep 2025 12:36:02 GMT) Full text and rfc822 format available.

Message #29 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79021 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>,
 eller.helmut <at> gmail.com
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Fri, 12 Sep 2025 08:35:36 -0400
>> >In any case, the fboundp test is not enough, we should test the value
>> >of dump-mode instead, I think.  Because Emacs might be built with
>> >pdumper support, but this session is not going to call
>> >dump-emacs-portable, due to command-line options or some other trick.
>> Just delete it.
> It's still useful if starting undumped Emacs, no?

Not really: its use was beneficial to try and keep the unexec'd `emacs`
compact, but it came at the cost of a slowdown.  The tradeoff was
positive then because we cared more about the size of the `emacs` binary
then about the slight increase to the build time.

But when starting Emacs un-dumped the benefit is mostly lost because in
that case we care more about minimizing the startup time than about
minimizing the size of the heap.

Helmut's patch looks good to me (you can remove the "probably" from the
comment, tho).


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Fri, 12 Sep 2025 12:49:01 GMT) Full text and rfc822 format available.

Message #32 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79021 <at> debbugs.gnu.org, dancol <at> dancol.org, eller.helmut <at> gmail.com
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Fri, 12 Sep 2025 15:48:05 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Daniel Colascione <dancol <at> dancol.org>,  eller.helmut <at> gmail.com,
>   79021 <at> debbugs.gnu.org
> Date: Fri, 12 Sep 2025 08:35:36 -0400
> 
> >> >In any case, the fboundp test is not enough, we should test the value
> >> >of dump-mode instead, I think.  Because Emacs might be built with
> >> >pdumper support, but this session is not going to call
> >> >dump-emacs-portable, due to command-line options or some other trick.
> >> Just delete it.
> > It's still useful if starting undumped Emacs, no?
> 
> Not really: its use was beneficial to try and keep the unexec'd `emacs`
> compact, but it came at the cost of a slowdown.  The tradeoff was
> positive then because we cared more about the size of the `emacs` binary
> then about the slight increase to the build time.
> 
> But when starting Emacs un-dumped the benefit is mostly lost because in
> that case we care more about minimizing the startup time than about
> minimizing the size of the heap.

But in that case, why do we need the fbound test at all?  The unexec
option is gone, so what other Emacs configuration will that test cater
to?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79021; Package emacs. (Fri, 12 Sep 2025 12:51:02 GMT) Full text and rfc822 format available.

Message #35 received at 79021 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79021 <at> debbugs.gnu.org, dancol <at> dancol.org, eller.helmut <at> gmail.com
Subject: Re: bug#79021: 31.0.50; Unnecessary GC in after-load-functions
Date: Fri, 12 Sep 2025 08:49:50 -0400
> But in that case, why do we need the fbound test at all?  The unexec
> option is gone,

Ah, right, forgot that we removed it.  Then we should just remove that
`add-hook`.


        Stefan





This bug report was last modified 7 days ago.

Previous Next


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