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: Sun, 12 Mar 2023 14:50:33 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I think that (2) is the most important factor for real world scenarios
> >
> > Not sure why you think so.  Maybe because I don't have a clear idea
> > what kind of fragmentation you have in mind here.
> 
> I meant that as long as gc-cons-threshold is much lower (10x or so) than
> heap size (Lisp object part), we do not need to worry about (1). Only
> (2) remains a concern.

Your gc-cons-threshold is 250 MiB.  If it's below 0.1 of the size of
Lisp data, does that mean you 2.5 GiB or more of Lisp data in your
sessions?  That's a lot.  I have less than 300 MiB, for comparison,
and this is a session that runs for 25 days non-stop, and has a
520 MiB memory footprint.

> 10% also means that 800k gc-cons-threshold does not matter much even
> with emacs -Q -- it uses over 8Mb memory and thus gc-cons-percentage
> should dominate the GC, AFAIU.

How did you measure those 8Mb?  On my system, memory-report in
"emacs -Q" shows less than 2 MiB in object memory.

> Note that my proposed 100Mb gc-cons-threshold limit will correspond to
> 1Gb live Lisp objects. For reference, this is what I have now (I got the
> data using memory-usage package):
> 
>    Total in lisp objects: 1.33GB (live 1.18GB, dead  157MB)

We need to align and calibrate our measurement means: what does
memory-report tell about object memory in that session?  1.18 GiB
sounds a lot.

> > Correction: it is _your_ init.el.  We need similar statistics from
> > many users and many different usage patterns; only then we will be
> > able to draw valid conclusions.
> 
> Sure. Should we formally try to call for such benchmarks?

Yes!

> > Actually, Emacs tries very hard to avoid fragmentation.  That's why it
> > compacts buffers, and that's why it can relocate buffer text and
> > string data.
> 
> Indeed. But despite all of the best efforts, fragmentation increases if
> we delay GCs, right?

Not IME, no.  That's why the memory footprint of a typical
long-running session levels out.