GNU bug report logs - #79074
31.0.50; Increase gc-cons-percentage in Makefiles

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 79074 in the body.
You can then email your comments to 79074 AT debbugs.gnu.org in the normal way.

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

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; Increase gc-cons-percentage in Makefiles
Date: Tue, 22 Jul 2025 17:27:11 +0200

It seems that the default value for gc-cons-percentage (10%) is very
conservative and hurts performance.

I did the following experiment: first, I built the master branch (with
-O2 and without checking); second, I executed this script:

for percentage in 0.1 0.75 1.5 ; do
    find lisp/ -name '*.elc' -exec rm -v {} +
    /usr/bin/time -o make-$percentage.time make -l3.2 -j4 \
BYTE_COMPILE_EXTRA_FLAGS="--eval '(setq gc-cons-percentage $percentage)'"\
lisp
done

The intention is to measure the time it takes to compile all the .el
files in the lisp directory for different values of gc-cons-percentage.
I get these results:

* for gc-cons-percentage = 0.1:
1697.81user 57.67system 12:08.57elapsed 240%CPU (0avgtext+0avgdata 202268maxresident)k
12424inputs+173840outputs (29major+9304710minor)pagefaults 0swaps

* for gc-cons-percentage = 0.75
1034.16user 61.77system 7:55.26elapsed 230%CPU (0avgtext+0avgdata 216888maxresident)k
42864inputs+172280outputs (157major+10152739minor)pagefaults 0swaps

* for gc-cons-percentage = 1.5
823.91user 65.62system 6:27.09elapsed 229%CPU (0avgtext+0avgdata 246948maxresident)k
118640inputs+171184outputs (106major+12651774minor)pagefaults 0swaps

We see that increasing gc-cons-percentage to 0.75 reduces the elapsed
real time considerably (from ~12 minutes to ~8); it increases maxrss from
203MB to 216MB, which seems quite modest.

So I think we should add something to BYTE_COMPILE_FLAGS to increase
gc-cons-percentage; or perhaps increase it in batch-byte-compile.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Tue, 22 Jul 2025 20:02:29 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Tue, 22 Jul 2025 17:27:11 +0200
> 
> It seems that the default value for gc-cons-percentage (10%) is very
> conservative and hurts performance.
> 
> I did the following experiment: first, I built the master branch (with
> -O2 and without checking); second, I executed this script:
> 
> for percentage in 0.1 0.75 1.5 ; do
>     find lisp/ -name '*.elc' -exec rm -v {} +
>     /usr/bin/time -o make-$percentage.time make -l3.2 -j4 \
> BYTE_COMPILE_EXTRA_FLAGS="--eval '(setq gc-cons-percentage $percentage)'"\
> lisp
> done
> 
> The intention is to measure the time it takes to compile all the .el
> files in the lisp directory for different values of gc-cons-percentage.
> I get these results:
> 
> * for gc-cons-percentage = 0.1:
> 1697.81user 57.67system 12:08.57elapsed 240%CPU (0avgtext+0avgdata 202268maxresident)k
> 12424inputs+173840outputs (29major+9304710minor)pagefaults 0swaps
> 
> * for gc-cons-percentage = 0.75
> 1034.16user 61.77system 7:55.26elapsed 230%CPU (0avgtext+0avgdata 216888maxresident)k
> 42864inputs+172280outputs (157major+10152739minor)pagefaults 0swaps
> 
> * for gc-cons-percentage = 1.5
> 823.91user 65.62system 6:27.09elapsed 229%CPU (0avgtext+0avgdata 246948maxresident)k
> 118640inputs+171184outputs (106major+12651774minor)pagefaults 0swaps
> 
> We see that increasing gc-cons-percentage to 0.75 reduces the elapsed
> real time considerably (from ~12 minutes to ~8); it increases maxrss from
> 203MB to 216MB, which seems quite modest.
> 
> So I think we should add something to BYTE_COMPILE_FLAGS to increase
> gc-cons-percentage; or perhaps increase it in batch-byte-compile.

We could certainly try that; patches welcome.

P.S. The above benchmark should be repeated with native-compilation,
IMO.

Thanks.

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

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Wed, 23 Jul 2025 14:03:44 +0200

[Message part 1 (text/plain, inline)]

On Tue, Jul 22 2025, Eli Zaretskii wrote:

[...]
>> So I think we should add something to BYTE_COMPILE_FLAGS to increase
>> gc-cons-percentage; or perhaps increase it in batch-byte-compile.
>
> We could certainly try that; patches welcome.

Here is a one:

[0001-Increase-gc-cons-percentage-when-building-.elc-files.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

> P.S. The above benchmark should be repeated with native-compilation,
> IMO.

I repeated it for "make bootstrap" because I don't know how to only
rebuild the lisp directory with native-compilation.

So basically I did:

for percentage in 0.1 0.75 1.5 ; do
    /usr/bin/time -o make-$percentage.time make -l3.2 -j4 \
 BYTE_COMPILE_EXTRA_FLAGS="--eval '(setq gc-cons-percentage $percentage)'" \
 FAST=true -l3.2 -j4 bootstrap
done

The results are:

* for gc-cons-percentage = 0.1:
2331.71user 86.23system 14:38.08elapsed 275%CPU (0avgtext+0avgdata 641880maxresident)k
4432inputs+742056outputs (18major+14952231minor)pagefaults 0swaps

* for gc-cons-percentage = 0.75:
1223.32user 85.96system 8:06.30elapsed 269%CPU (0avgtext+0avgdata 706240maxresident)k
0inputs+742064outputs (2major+15873839minor)pagefaults 0swaps

* for gc-cons-percentage = 1.5:
961.91user 94.57system 6:32.58elapsed 269%CPU (0avgtext+0avgdata 766348maxresident)k
16inputs+742064outputs (0major+18617902minor)pagefaults 0swaps

[BTW, boostrapping the igc branch requires:
1039.27user 181.75system 7:19.31elapsed 277%CPU (0avgtext+0avgdata 929092maxresident)k
38960inputs+682528outputs (8major+27973694minor)pagefaults 0swaps ]

For fun, I also recorded the times for individual compilation processes.
Here a scatter plot of the result:

[elc.svgz (image/svg+xml, attachment)]

[Message part 5 (text/plain, inline)]

Some statistics:

 gc-cons-percentage │ variable  mean       min      median   max    
────────────────────┼───────────────────────────────────────────────
                0.1 │ real      1.3452     0.12     0.48     162.52 
                0.1 │ rssmax    51622.8    42692    45388.0  641880 
		    │
               0.75 │ real      0.660551   0.1      0.285    69.69  
               0.75 │ rssmax    54213.1    43032    47932.0  706240 
	            │
                1.5 │ real      0.507625   0.08     0.22     62.93  
                1.5 │ rssmax    60135.5    43060    55508.0  766348 

and here the full tables, if somebody is interested:

[elc-0.1.csv.gz (application/gzip, attachment)]

[elc-0.75.csv.gz (application/gzip, attachment)]

[elc-1.5.csv.gz (application/gzip, attachment)]

Message #14 received at 79074 <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: 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Sat, 26 Jul 2025 12:59:55 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: 79074 <at> debbugs.gnu.org
> Date: Wed, 23 Jul 2025 14:03:44 +0200
> 
> On Tue, Jul 22 2025, Eli Zaretskii wrote:
> 
> [...]
> >> So I think we should add something to BYTE_COMPILE_FLAGS to increase
> >> gc-cons-percentage; or perhaps increase it in batch-byte-compile.
> >
> > We could certainly try that; patches welcome.
> 
> Here is a one:

Thanks, LGTM.  Stefan, any comments?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Sat, 26 Jul 2025 10:19:34 -0400

> It seems that the default value for gc-cons-percentage (10%) is very
> conservative and hurts performance.

It is definitely very conservative.  But it's used only in
interactive mode, not in batch mode:

    % src/emacs -Q --batch --eval '(message "%S" gc-cons-percentage)'
    1.0
    %

FWIW, in my interactive mode, I set it to 0.5 so as to try and reduce
the occurrences of GC while I use Emacs, and then have an idle timer
that tries to run Emacs during pauses so as to recover some of the
benefits of more frequent GCs (and to try and avoid running GCs in the
middle of a command):

Here are the stats for this Gnus process:

    M-x gc--opportunistic-score RET
    ((jit 1 0 0) (opportunistic-gcs . 2744) (cmd 104 11 28) (earlier-gcs . 69) (noncmd 18 6 16) (commands . 369311))

IOW, the GC ran 2744 times during idle time, it ran 132 times during
a command (104 of which were "single-run", i.e. a single GC in that
command, while the other 28 were spread over only 11 commands, so those
are GCs that are hard to avoid bby delaying the GC to idle time because
the commands just use a lot of memory), it ran 34 times during a "non
command" (process filters?  timers?) and it ran once during jit-lock.
That was during the execution of 369311 commands.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79074 <at> debbugs.gnu.org, eller.helmut <at> gmail.com
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Sat, 26 Jul 2025 17:26:06 +0300

> Cc: 79074 <at> debbugs.gnu.org
> Date: Sat, 26 Jul 2025 10:19:34 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > It seems that the default value for gc-cons-percentage (10%) is very
> > conservative and hurts performance.
> 
> It is definitely very conservative.  But it's used only in
> interactive mode, not in batch mode:
> 
>     % src/emacs -Q --batch --eval '(message "%S" gc-cons-percentage)'
>     1.0
>     %

So you are saying that perhaps we should simply increase the current
value of 1.0 to 1.2, for all non-interactive sessions?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Sat, 26 Jul 2025 11:14:48 -0400

> For fun, I also recorded the times for individual compilation processes.
> Here a scatter plot of the result:

Nice, thanks!

> Some statistics:
>
>  gc-cons-percentage │ variable  mean       min      median   max    
> ────────────────────┼───────────────────────────────────────────────
>                 0.1 │ real      1.3452     0.12     0.48     162.52 
>                 0.1 │ rssmax    51622.8    42692    45388.0  641880 
> 		      │
>                0.75 │ real      0.660551   0.1      0.285    69.69  
>                0.75 │ rssmax    54213.1    43032    47932.0  706240 
> 	              │
>                 1.5 │ real      0.507625   0.08     0.22     62.93  
>                 1.5 │ rssmax    60135.5    43060    55508.0  766348 

What kind of "mean" is that?  I think an arithmetic mean doesn't make
much sense for such values, so I hope it was a geometric mean.
Maybe the quartiles would be handy as well.

The rssmax increase from 0.75 to 1.5 suggests that 1.5 is reaching the
limit of the "free gains", but the reduction in real time shows there is
still a gain (in comparison the rssmax increase from 0.1 to 0.75 is
small enough that the real time reduction can be considered a "free
gain").


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79074 <at> debbugs.gnu.org, eller.helmut <at> gmail.com
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Sat, 26 Jul 2025 11:18:13 -0400

>> It is definitely very conservative.  But it's used only in
>> interactive mode, not in batch mode:
>> 
>>     % src/emacs -Q --batch --eval '(message "%S" gc-cons-percentage)'
>>     1.0
>>     %
>
> So you are saying that perhaps we should simply increase the current
> value of 1.0 to 1.2, for all non-interactive sessions?

No, just that 0.1 is not the baseline.

But yes, I think I'm also saying that rather than change it just for
compilation, if we want to change it, we should change it in src/emacs.c
for all batch uses.

FWIW, the 1.0 value used nowadays was not carefully chosen.  It was
based on a kind of rule of thumb that mark&sweep GCs generally require
about double the memory in order to work efficiently.
It's a *very* rough rule.  I don't have a strong opinion on whether 1.0
or 1.2  is best, or even whether it's worth trying to find the
"optimal" choice.

But if we do want to fine tune it, maybe it'd be worth re-running
Helmut's measurements for more values, like 0.8, 1, 1.25, 1.6, 2.0, 4.0
to have a more complete picture (I skipped the 2.5 and 3.2 steps because
I expect the difference between 2.0 and 4.0 will already show that this
is beyond the point of diminishing returns).


        Stefan

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

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Mon, 28 Jul 2025 13:19:12 +0200

On Sat, Jul 26 2025, Stefan Monnier wrote:

>> It seems that the default value for gc-cons-percentage (10%) is very
>> conservative and hurts performance.
>
> It is definitely very conservative.  But it's used only in
> interactive mode, not in batch mode:
>
>     % src/emacs -Q --batch --eval '(message "%S" gc-cons-percentage)'
>     1.0
>     %

Ah, I didn't know that; but it makes sense.  Which means that the bug
can be closed.

> FWIW, in my interactive mode, I set it to 0.5 so as to try and reduce
> the occurrences of GC while I use Emacs, and then have an idle timer
> that tries to run Emacs during pauses so as to recover some of the
> benefits of more frequent GCs (and to try and avoid running GCs in the
> middle of a command):
>
> Here are the stats for this Gnus process:
>
>     M-x gc--opportunistic-score RET
>     ((jit 1 0 0) (opportunistic-gcs . 2744) (cmd 104 11 28) (earlier-gcs . 69) (noncmd 18 6 16) (commands . 369311))
>
> IOW, the GC ran 2744 times during idle time, it ran 132 times during
> a command (104 of which were "single-run", i.e. a single GC in that
> command, while the other 28 were spread over only 11 commands, so those
> are GCs that are hard to avoid bby delaying the GC to idle time because
> the commands just use a lot of memory), it ran 34 times during a "non
> command" (process filters?  timers?) and it ran once during jit-lock.
> That was during the execution of 369311 commands.

I suppose you collect this data in pre/post-command-hooks?

Helmut

Message #32 received at 79074 <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>, 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Mon, 28 Jul 2025 13:24:43 +0200

[Message part 1 (text/plain, inline)]

On Sat, Jul 26 2025, Stefan Monnier wrote:

[...]
> But if we do want to fine tune it, maybe it'd be worth re-running
> Helmut's measurements for more values, like 0.8, 1, 1.25, 1.6, 2.0, 4.0
> to have a more complete picture (I skipped the 2.5 and 3.2 steps because
> I expect the difference between 2.0 and 4.0 will already show that this
> is beyond the point of diminishing returns).

That produces:

| gc-cons-percentage |  elapsed |  rssmax |
|--------------------+----------+---------|
|                0.1 | 14:38.08 |  641880 |
|               0.75 |  8:06.30 |  706240 |
|                0.8 |  7:36.43 |  705732 |
|                1.0 |  6:58.86 |  652292 |
|               1.25 |  6:38.75 |  710320 |
|                1.5 |  6:32.58 |  766348 |
|                1.6 |  6:14.64 |  776856 |
|                2.0 |  5:57.64 | 4655076 |
|                4.0 |  6:08.25 | 4652808 |

Not sure why there is this sudden jump for rssmax in the 2.0 row; it
looks strangely non-linear.  Other than that, it looks like
gc-cons-percentage = 1.0 is a reasonable choice.


The statistics for the individual processes:

| gc-cons-% |           elapsed real time            |            rssmax                             |    
|           |  min |  q25 | median |    q75 |    max |   min |     q25 |  median |     q75 |     max |
|-----------+------+------+--------+--------+--------+-------+---------+---------+---------+---------|
|       0.1 | 0.12 | 0.19 |   0.48 |   0.81 | 162.52 | 42692 | 44092.0 | 45388.0 | 47996.0 |  641880 |
|      0.75 |  0.1 | 0.14 |  0.285 |   0.42 |  69.69 | 43032 | 45085.0 | 47932.0 | 51235.0 |  706240 |
|       0.8 | 0.09 | 0.14 |   0.27 |   0.39 |  67.02 | 42820 | 44885.0 | 47730.0 | 50707.0 |  705732 |
|       1.0 |  0.1 | 0.13 |   0.25 |   0.37 |  64.11 | 42800 | 45488.0 | 49548.0 | 52249.0 |  652292 |
|      1.25 | 0.08 | 0.13 |   0.23 | 0.3275 |  60.51 | 43344 | 46142.0 | 50638.0 | 54487.0 |  710320 |
|       1.5 | 0.08 | 0.12 |   0.22 |   0.31 |  62.93 | 43060 | 45984.0 | 55508.0 | 57521.0 |  766348 |
|       1.6 | 0.09 | 0.12 |    0.2 |   0.31 |  60.36 | 43552 | 45240.0 | 55282.0 | 60530.0 |  776856 |
|       2.0 | 0.08 | 0.11 |   0.19 |   0.28 |  59.88 | 43348 | 46318.0 | 57808.0 | 72712.0 | 4655076 |
|       4.0 | 0.08 | 0.11 |   0.19 |   0.28 |  59.47 | 43424 | 46357.0 | 57906.0 | 72711.0 | 4652808 |

The same as boxplot:

[elc.svg.gz (application/gzip, attachment)]

[Message part 3 (text/plain, inline)]

The "without outliers" variants show the data without the dots above the
whiskers.  The whiskers are at 1.5 * interquartile-range.

Helmut

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Mon, 28 Jul 2025 13:07:51 -0400

> [...]
>> But if we do want to fine tune it, maybe it'd be worth re-running
>> Helmut's measurements for more values, like 0.8, 1, 1.25, 1.6, 2.0, 4.0
>> to have a more complete picture (I skipped the 2.5 and 3.2 steps because
>> I expect the difference between 2.0 and 4.0 will already show that this
>> is beyond the point of diminishing returns).
>
> That produces:
>
> | gc-cons-percentage |  elapsed |  rssmax |
> |--------------------+----------+---------|
> |                0.1 | 14:38.08 |  641880 |
> |               0.75 |  8:06.30 |  706240 |
> |                0.8 |  7:36.43 |  705732 |
> |                1.0 |  6:58.86 |  652292 |
> |               1.25 |  6:38.75 |  710320 |
> |                1.5 |  6:32.58 |  766348 |
> |                1.6 |  6:14.64 |  776856 |
> |                2.0 |  5:57.64 | 4655076 |
> |                4.0 |  6:08.25 | 4652808 |
>
> Not sure why there is this sudden jump for rssmax in the 2.0 row; it
> looks strangely non-linear.

The impact on the memory use depends on things like fragmentation,
blocks of code where we inhibit GC, and could also interact with the
conservative scanning of the stack (a larger heap increases the
likelihood of finding false positives), so I'm not completely surprised
there are non-linearities.

> Other than that, it looks like gc-cons-percentage = 1.0 is
> a reasonable choice.

Your data shows that 1.0 is not a terrible choice and that it is on the
conservative side (based on your data, a choice like 1.6 would be
closer to my idea of "optimal"), so all in all, I think it matches our
goal fairly well.  🙂

> The same as boxplot:
>
> The "without outliers" variants show the data without the dots above the
> whiskers.  The whiskers are at 1.5 * interquartile-range.

Thanks.  I guess the outliers do illustrate the risks involved in
setting that tunable "too high".

I'm surprised q75 for rssmax is (ever so slightly) lower for 4.0 than
for 2.0.


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 79074 <at> debbugs.gnu.org
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Mon, 28 Jul 2025 13:10:34 -0400

>> Here are the stats for this Gnus process:
>>
>>     M-x gc--opportunistic-score RET
>>     ((jit 1 0 0) (opportunistic-gcs . 2744) (cmd 104 11 28) (earlier-gcs
>> . 69) (noncmd 18 6 16) (commands . 369311))
> I suppose you collect this data in pre/post-command-hooks?

Mostly, yes.  See code below.


        Stefan


;;;; Opportunistic GC

;; Scores so far (single-gc-cmds / opportunistic / total gcs):
;; 0 / 0 / 80  (Gnus)
;; 0 / 0 / 100 (X with Org)
;; 41 / 0 / 228 (Gnus)
;; 32 / 178 / 450      (X)
;; 3427 / 6911 / 11388 (Gnus)

;; Without opportunistic GC:
;;   X: ((multi-gcs . 128) (multi-gc-cmds . 25) (single-gc-cmds . 357) (commands . 128966))
;;   Gnus: ((single-gc-cmds . 961) (multi-gcs . 1004) (multi-gc-cmds . 334) (commands . 122678))
;; With opportunistic GC:
;;   ((multi-gcs . 103) (multi-gc-cmds . 28) (single-gc-cmds . 333) (noncmds-gcs . 4485) (noncmds . 4369) (earlier-gcs . 52) (opportunistic-gcs . 1557) (commands . 156917))



(defvar gc--opportunistic-last-gcs gcs-done)
(defvar gc--opportunistic-state 'noncmd)
(defvar gc--opportunistic-counters nil)

(defun gc--opportunistic-record (nextstate)
  (let ((counts (alist-get gc--opportunistic-state gc--opportunistic-counters)))
    (unless counts
      (setf (alist-get gc--opportunistic-state gc--opportunistic-counters)
            (setq counts (list 0 0 0))))
    (pcase (prog1 (- gcs-done gc--opportunistic-last-gcs)
             (setq gc--opportunistic-last-gcs gcs-done))
      ((pred (>= 0)) nil)
      (1 (cl-incf (nth 0 counts)))
      (gcs (cl-incf (nth 1 counts))
           (cl-incf (nth 2 counts) gcs))))
  (setq gc--opportunistic-state nextstate))

(defun gc--opportunistic-postch ()
  (cl-incf (alist-get 'commands gc--opportunistic-counters 0))
  (gc--opportunistic-record 'noncmd))

(defun gc--opportunistic-prech ()
  (cl-callf identity
      (alist-get 'earlier-gcs gc--opportunistic-counters gcs-done))
  (gc--opportunistic-record 'cmd))

(defun gc--opportunistic-jitlock (orig-fun start)
  (if (eq gc--opportunistic-state 'cmd)
      ;; Count jit-lock execution which happens during a command as
      ;; being part of command execution rather than as part of jit-lock!
      (funcall orig-fun start)
    (let ((gc--opportunistic-state gc--opportunistic-state))
      (gc--opportunistic-record 'jit)
      (unwind-protect
          (funcall orig-fun start)
        (gc--opportunistic-record 'postjit)))))

(add-hook 'pre-command-hook #'gc--opportunistic-prech)
(add-hook 'post-command-hook #'gc--opportunistic-postch)
(advice-add 'jit-lock-function :around #'gc--opportunistic-jitlock)

(defun gc--opportunistic ()
  "Run the GC during idle time."
  ;; This is good for two reasons:
  ;; - It reduces the number of times we have to GC in the middle of
  ;;   an operation.
  ;; - It means we GC when the C stack is short, reducing the risk of false
  ;;   positives from the conservative stack scanning.
  (unless (> gc-cons-percentage 0.1)
    (setq gc-cons-percentage 0.5))
  (when (garbage-collect-maybe 10)
    (cl-incf (alist-get 'opportunistic-gcs gc--opportunistic-counters 0))
    ;; Don't double count this GC in other categories.
    (cl-incf gc--opportunistic-last-gcs)
    ;; Recalibrate the timer.
    (cancel-function-timers #'gc--opportunistic)
    (run-with-idle-timer
     ;; FIXME: Magic formula!
     (+ 1 (* 10 (/ gc-elapsed gcs-done))) t #'gc--opportunistic)))


(defun gc--opportunistic-score ()
  "Show the current counters's that keep track of GC behavior."
  (interactive)
  (message "%S" gc--opportunistic-counters))

Message #43 received at 79074-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 79074-done <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#79074: 31.0.50; Increase gc-cons-percentage in Makefiles
Date: Sat, 02 Aug 2025 17:22:18 +0300

> Cc: 79074 <at> debbugs.gnu.org
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Mon, 28 Jul 2025 13:19:12 +0200
> 
> On Sat, Jul 26 2025, Stefan Monnier wrote:
> 
> >> It seems that the default value for gc-cons-percentage (10%) is very
> >> conservative and hurts performance.
> >
> > It is definitely very conservative.  But it's used only in
> > interactive mode, not in batch mode:
> >
> >     % src/emacs -Q --batch --eval '(message "%S" gc-cons-percentage)'
> >     1.0
> >     %
> 
> Ah, I didn't know that; but it makes sense.  Which means that the bug
> can be closed.

Thanks, closing.

Previous Next

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