GNU bug report logs -
#79021
31.0.50; Unnecessary GC in after-load-functions
Previous Next
To reply to this bug, email your comments to 79021 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
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: 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):
>> 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):
[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: 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):
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):
> 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):
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):
>> >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: 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):
> 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.