[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Eager garbage collection
From: |
Spencer Baugh |
Subject: |
Re: Eager garbage collection |
Date: |
Sun, 22 Nov 2020 00:07:31 -0500 |
Eli Zaretskii <eliz@gnu.org> writes:
> I'm trying to understand whether we should enable this by default or
> not. The decision should depend on the overall effect of this
> feature, and on whether it has any downsides. IME, changes in GC
> details frequently have unintended consequences. Can you present some
> evidence of the effect of using the feature, either measurements or
> even anecdotal evidence?
>
> More generally, perhaps we need some tools to measure the effect of
> this (e.g., how many GC's happened during some rime interval, how much
> time each GC took, how large is the VM size of Emacs, etc. Then we
> could ask people to present numbers with and without the feature, and
> make the decision based on that.
One easy thing is to count how many GCs actually get triggered by the
idle opportunistic logic, and compare that to the total GCs. That is a
proxy for some other properties, including "Is this moving substantial
numbers of GCs to run while idle?"
My v2 of the patch series adds such a counter (in addition to fixing the
style issues you mentioned); I'll send that shortly.
Spencer Baugh (3):
Add gc-estimated-time variable
Add garbage-collect-maybe function
Start opportunistic GC timer at startup
lisp/startup.el | 56 +++++++++++++++++++++++++++++++++++++++++++++++++
src/alloc.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++--
src/lisp.h | 1 +
3 files changed, 110 insertions(+), 2 deletions(-)
I'll run this for a while and see how it goes for me...
This doesn't answer the "What effect does this have on the input latency
experienced by the user?" question, though, which I think is perhaps the
most important question. Not sure how to answer it, since it will
depend on user configurations and behavior.
The ultimate last resort for this question is to just add it, disabled
by default; then we can get feedback from users who enable it. But
maybe we can find enough information to persuade ourselves that it is
good without having to wait for an entire release cycle like that.
Andrea, do you have any thoughts from GCMH on how to performance test
this?
- Re: Eager garbage collection, (continued)
- Re: Eager garbage collection, Spencer Baugh, 2020/11/18
- Re: Eager garbage collection, Andrea Corallo, 2020/11/18
- Re: Eager garbage collection, Stefan Monnier, 2020/11/18
- Re: Eager garbage collection, Andrea Corallo, 2020/11/18
- Re: Eager garbage collection, Eli Zaretskii, 2020/11/18
- Re: Eager garbage collection, Eli Zaretskii, 2020/11/18
- Re: Eager garbage collection,
Spencer Baugh <=
- [PATCH v2 1/3] Add gc-estimated-time variable, Spencer Baugh, 2020/11/22
- Re: [PATCH v2 1/3] Add gc-estimated-time variable, Eli Zaretskii, 2020/11/22
- Re: [PATCH v2 1/3] Add gc-estimated-time variable, Stefan Monnier, 2020/11/22
- [PATCH v2 2/3] Add garbage-collect-maybe function, Spencer Baugh, 2020/11/22
- Re: [PATCH v2 2/3] Add garbage-collect-maybe function, Eli Zaretskii, 2020/11/22
- [PATCH v2 3/3] Start opportunistic GC timer at startup, Spencer Baugh, 2020/11/22
- Re: Eager garbage collection, Eli Zaretskii, 2020/11/22
- Re: Eager garbage collection, yyoncho, 2020/11/18
- Re: Eager garbage collection, Eli Zaretskii, 2020/11/18
- Re: Eager garbage collection, Stefan Monnier, 2020/11/18