Re: Indentation and gc

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org
> Date: Wed, 15 Mar 2023 12:59:05 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Then, from what I can read, it does not look like VIRT truly represents
> >> how much memory Emacs is going to use. It is safe to assume that only a
> >> fraction of VIRT will be used in practice.
> >
> > I don't think I follow your logic.
> >
> > Emacs can have more memory in use than the physically installed
> > amount, it just means each GC will be painfully slow, because it will
> > need to swap in parts of memory and swap out other parts.  In theory,
> > Emacs can use all the VM there is, minus what other processes and the
> > OS use.
> >
> > If your bother is about the "reserved" part, that is not supposed to
> > be large, but maybe glibc has its own ideas about that, because your
> > report about VIRT vs RES surprised me.
> 
> Then what should we collect from user session?
> memory-limit represents VIRT, but it does not look terribly useful.
> 
> What exactly should we use as a metric for the effects of
> gc-cons-threshold changes?

I guess the output of memory-info should be good, in addition to
memory-limit.  I do think memory-limit is useful, albeit we should
take it with a grain of salt sometimes.  A too-large difference
between memory-limit and the resident set size is perhaps already an
important indication of some trouble, although I'd like to see more
examples to make up my mind about that.

But that's the possible downside of higher GC thresholds; other
important indications are the time spent in GC and the average
duration of a GC cycle.