On 1/19/25 12:36 PM, Stefan Kangas wrote: > Alexis Purslane via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" 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)? > I use GCMH with emacs 29.4, but I have it turned off for emacs 31.0.50, Because I figured it probably wouldn't do anything, and even if it did, it would probably muddy the waters for debugging purposes.