GNU bug report logs -
#75672
31.0.50; scratch/igc memory usage/collection issues
Previous Next
Reported by: Alexis Purslane <alexispurslane <at> pm.me>
Date: Sun, 19 Jan 2025 17:01:02 UTC
Severity: normal
Found in version 31.0.50
Done: Pip Cet <pipcet <at> protonmail.com>
Bug is archived. No further changes may be made.
Full log
Message #11 received at 75672 <at> debbugs.gnu.org (full text, mbox):
Alexis Purslane via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> 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)?
This bug report was last modified 81 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.