Subject: Re: bug#45200: [PATCH] Force Glibc to free the memory freed

From: Konstantin Kharlamov <[email-masked]>
Date: Wed, 03 Feb 2021 10:15:19 +0300

On Wed, 2021-02-03 at 09:07 +0200, Eli Zaretskii wrote:
> On February 3, 2021 8:04:21 AM GMT+02:00, Konstantin Kharlamov
> <[email-masked]> wrote:
> > On Tue, 2021-02-02 at 23:50 -0500, Stefan Monnier wrote:
> > > > >     with malloc_trim:
> > > > >         (8.920371394 232 2.106283245)
> > > > >         (9.038083601 231 2.060810826)
> > > > >         (9.140798641 231 2.0594013240000004)
> > > > > 
> > > > >     without malloc_trim:
> > > > >         (8.987097209 232 2.070143482)
> > > > >         (8.700478084 231 1.7745506179999997)
> > > > >         (8.781121056 231 1.7870093610000004)
> > > > > 
> > > > > The difference is just 3-4% (8.7 / 9 ≈ 0.9666666667). It looks
> > to me
> > > > > insignificant enough to not show up anywhere during interactive
> > work
> > > > > with Emacs.
> > > > 
> > > > It's indeed not too costly, but what about the upside?
> > > 
> > > BTW, maybe a better way forward than trying to convince us that it's
> > > a good default (which could be hard if the upside is a reduction of
> > the
> > > memory use by a few percent: for many people it might be less
> > > relevant/noticeable than the corresponding few percents lost in
> > speed)
> > > is to provide a patch that adds a new *ELisp* function that calls
> > > `malloc_trim`, which you can then add to `post-gc-hook` in your init
> > > file when your usage pattern makes it useful.
> > 
> > Upside indeed is the memory reduction.
> 
> How much memory reduction?  Can you show the numbers?

Sure. When I run the testcase for the problem that I posted in 3rd email on this thread¹, vanilla Emacs takes up 260.3M of PSS and never goes below, not even upon re-running (garbage-collect) manually. The patched Emacs on the other hand has 64.3M of PSS right after the testcase finishes.

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45200#11