Re: Larger GC thresholds for non-interactive Emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  yantar92@gmail.com,  mattiase@acm.org,
>   theophilusx@gmail.com,  rms@gnu.org,  acm@muc.de,  emacs-devel@gnu.org
> Date: Sun, 19 Jun 2022 13:02:59 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIK, that's not really true.  We call 'free' and glibc does release
> > to the OS when it can.  And don't forget that Emacs calls 'malloc' a
> > lot not just for conses and other Lisp data.
> 
> Wasn't there a huge discussion about this a couple months ago and the
> conclusion was that glibc rarely releases memory back to the OS?  That's
> why we added `malloc-trim'.

Well, "rarely" is not the same as "never".

How rare is "rarely" really depends on the specific use patterns, and
I don't think we have ever established what kinds of uses cause us to
release memory more frequently than others.

Maybe it's worth our while to collect some data about this?  For
example, frequent contributors who tend to run Emacs for many days
could perhaps take a snapshot of the total VM of the Emacs process and
see how it behaves.  Then we'd know how frequently the footprint goes
down and by how much.

I can tell from my own experience that, when I purge my mail INBOX,
typically leaving about 2500 email messages in it down from ~4500, the
memory footprint of the Emacs process goes down from about 620 MB to
about 520-550 MB.  But this is not with glibc.