Subject: bug#75672: 31.0.50; scratch/igc memory usage/collection issues

From: Stefan Kangas <[email-masked]>
Date: Sun, 19 Jan 2025 11:36:58 -0600

Alexis Purslane via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <[email-masked]> writes:

> I've been using scratch/igc for the past few days (see details below for
> the exact version and situation) and have been having some /interesting/
> experiences:
>
>     1. It seems slower than Emacs 29.4 with GCMH (gcmh-idle-timer set to
>     'auto, so it GCs usually after less than a second of idle time, and
>     gcmh-max-cons-threshold set to 200MB so that if there's a very
>     intense operation going on that's allocating a lot of memory, it
>     will actually GC before it gets out of hand and the idle GC pause
>     would freeze Emacs, but most of the time it'll almost never GC
>     unless I'm idle) when opening a lot of files (for instance, when
>     running org-agenda). About twice as slow. Startup is faster, though.

Thanks for the report.  I'm repyling only to the GCMH part here.

For context, GCMH is a package by Andrea that tries to avoid GC by
setting a high `gc-cons-threshold` when Emacs is in use, and then
triggers GC when Emacs is idle.  Details here:

    https://elpa.gnu.org/packages/gcmh.html

Do we expect that running GCMH will be useful with IGC?

First, I'm not sure that `gc-cons-threshold` will even affect MPS.

Second, we already run 'igc_on_idle' periodically.

Third, GCMH will run `garbage-collect`, which doesn't trigger a full GC
with MPS, AFAIU by design.  GCMH would need to run `igc--collect`, but
according to Gerd we should treat that function as a debugging tool.

Maybe GCMH should simply do nothing if (featurep 'mps)?