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

[Konstantin Kharlamov <hi-angel@yandex.ru>]

On Wed, 2021-02-03 at 10:15 -0500, Stefan Monnier wrote:
> > Stefan, what do you think? Will it be okay if I implement a patch that runs
> > `malloc_trim(0)` when Emacs is idle?
> 
> That's yet another reason why we should provide that function to ELisp,
> and then have ELisp decide when it's called (whether after GC, or on
> idle or what).

Okay, let's discuss this idea. It seems that running `malloc_trim(0)` on idle (let's say, after 10 seconds of idling, which implies a user might have switch to a browser, or something) should resolve all performance concerns. Especially given, measurements show it has pretty negligible impact even when located on return from GC.

To answer you question in another email about memory benefits given default Emacs settings: well, today I tried creating a testcase that would reproduce problem with default settings, but haven't really succeeded at it. I have a testcase where Emacs without the patch has ≈20M more memory than the one with the patch, but that's pretty small difference, and offhand I didn't manage to get it increased any further.

So, I'm thinking of wiring the functional of memory trimming to on-idle hook, without possibility to disable it. Given how small performance impact in this case would be, I see no reason to even implement an option to disable it.

Thoughts?