On Tue, 2021-01-26 at 10:30 -0500, Stefan Monnier wrote:
> > That'd be easy to implement, but I'm not yet sure it's the best
> > alternative.  In particular, I'd like to have some idea regarding how
> > much time such a call could take.  In some usage patterns Emacs calls
> > GC very frequently, which slows down command execution and makes Emacs
> > less responsive.
>
> The most important case where this happens is during phases of creation
> of large new structures (e.g. while loading a large package like Org),
> where a lot of memory is allocated without generating much garbage, so
> every time we run the GC that time is mostly wasted (since we don't
> recover any garbage) and calling malloc_trim would also be useless in
> those cases.

So, I just did some benchmarking; the patch I bencharked it with was modified per Stefan's comment (i.e. `malloc_trim(0)` is moved to the end of `garbage_collec()`). I'm attaching it here as well.

Benchamarking was done as follows: I ran built emacs as `src/emacs -Q`; and used this code

    (benchmark-run
        (let ((i 1000000))
          (while (> i 0)
            (print "hello")
            (setq i (- i 1)))))

which I ran 3 times. First with the patch; then I git-checked out HEAD^ (i.e. to the code without my patch), built it, and ran 3 times again.

This code you may recognize, it was the reproducer to show Emacs taking 200M of memory, except I cut out the line disabling GC, and the line that calls GC manually. IOW I used a known memory-heavy testcase, and ran it with vanilla Emacs configuration.

Results are:

    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.