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

[DJ Delorie]

Eli Zaretskii <eliz@gnu.org> writes:
>> The problem we're dealing here with is an actual bug in glibc⁵. What
>> this implies is that if the fix indeed hurts performance someplace,
>> well, then it's that this place requires additional
>> performance-related fixes. As opposed to just ignoring the bug
>> because of performance got somewhere decreased. Things like, changing
>> the slow algorithm, or modifying GC behavior for specific usecases…
>
> The fact that the bug you reported didn't get any responses in  more
> than a month, let alone wasn't fixed, could be a sign that not
> everyone agrees this is a bug...

Right, glibc's malloc maintains a cache of re-usable chunks of memory,
for performance reasons.  That cache, obviously, costs memory.
malloc_trim() flushes that cache and returns memory to the kernel.  That
has two effects: first, your memory footprint is smaller, but second,
your performance will suffer until the cache is refilled.

We (glibc devs) don't consider "poor cache performance for my
application" to be a bug.  A patch which improves cache performance *for
most apps* would be considered, but a patch that improves one app's
speed at the cost of most other apps, would be rejected.

You (emacs devs) need to decide whether you care more about memory
footprint or memory performance, and tune malloc accordingly.
malloc_trim() is one knob to tune, there are others.  But don't say it's
a "bug" if our defaults don't match your optimal settings.