[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45200: [PATCH] Force Glibc to free the memory freed
From: |
Konstantin Kharlamov |
Subject: |
bug#45200: [PATCH] Force Glibc to free the memory freed |
Date: |
Wed, 03 Feb 2021 00:17:02 +0300 |
User-agent: |
Evolution 3.38.3 |
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.
1.patch
Description: Text Data
- bug#45200: [PATCH] Force Glibc to free the memory freed,
Konstantin Kharlamov <=
- bug#45200: [PATCH] Force Glibc to free the memory freed, Stefan Monnier, 2021/02/02
- bug#45200: [PATCH] Force Glibc to free the memory freed, Stefan Monnier, 2021/02/02
- bug#45200: [PATCH] Force Glibc to free the memory freed, martin rudalics, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, martin rudalics, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/03
- bug#45200: [PATCH] Force Glibc to free the memory freed, Konstantin Kharlamov, 2021/02/03