diff options
Diffstat (limited to '2023/talks/gc.md')
| -rw-r--r-- | 2023/talks/gc.md | 42 |
1 files changed, 21 insertions, 21 deletions
diff --git a/2023/talks/gc.md b/2023/talks/gc.md index c7018d2f..dac7add0 100644 --- a/2023/talks/gc.md +++ b/2023/talks/gc.md @@ -14,7 +14,7 @@ Ihor Radchenko (he) - Mastodon: <https://emacs.ch/@yantar92>, <mailto:yantar92@p Talk sources, PDF, raw data, and analysis are published at <https://dx.doi.org/10.5281/zenodo.10213384> . Is Emacs responsiveness really affected by slow garbage collector? -Should \`gc-cons-threshold' be increased during startup? +Should `gc-cons-threshold' be increased during startup? Or maybe during the whole Emacs session? I will try to answer these questions using the real data collected from @@ -37,50 +37,50 @@ https://yhetil.org/emacs-devel/87v8j6t3i9.fsf@localhost/ - Q: Are the GC duration statistics correlated with users? I mean: does the same user experience GCs of various durations, or do some - users experience GCs of \>0.2 s exclusively while others never - experience GCs of \>0.2 s? - - A: Some users have \<0.1 GC time, while others struggle with + users experience GCs of >0.2 s exclusively while others never + experience GCs of >0.2 s? + - A: Some users have <0.1 GC time, while others struggle with near 1 sec. Really varies. But the number of people - with \>0.2sec is significant enough to make GC a big deal. You + with >0.2sec is significant enough to make GC a big deal. You can check it yourself - there are GC stats plots for each individual user in <https://zenodo.org/records/10213384>. - Q:Having recently been working on a high-performance smooth scrolling mode, which needs to respond to scroll events - arriving \>50-60 times per second, a 100ms delay is \*very\* + arriving >50-60 times per second, a 100ms delay is *very* noticeable in this scenario. For normal buffer interation and - commands 0.1s a reasonable dividing line, but I\'d estimate you can - easily feel a 20ms delay during varoius \"fast\" interactions. Do - you think there is hope to \"spread out\" GC latency to keep it + commands 0.1s a reasonable dividing line, but I'd estimate you can + easily feel a 20ms delay during varoius "fast" interactions. Do + you think there is hope to "spread out" GC latency to keep it below say 15ms, even if more frequent (without just repeating many - short GC\'s in a row)? - - A: The only reasonable \"spread out\" is deferring GC to - \_after\_ that scrolling. Like (let ((gc-cons-threshold \<large - enough number to avoid multiple GCs\>)) (do the scrolling)). + short GC's in a row)? + - A: The only reasonable "spread out" is deferring GC to + _after_ that scrolling. Like (let ((gc-cons-threshold <large + enough number to avoid multiple GCs>)) (do the scrolling)). This is also what recommended by Emacs devs (AFAIR). - Q:Opinions about gcmh-mode? - A: (Not Ihor): Ironically it uses too many timers, creating - garbage of its own. It should use \`timer-set-time\` instead of + garbage of its own. It should use `timer-set-time` instead of creating and throwing away timers after each command (via - \`post-command-hook\`) Interesting! + `post-command-hook`) Interesting! - A: (from Ihor): the problem is it ends up consuming a ton of memory, increasing GC time, and that most GCs occur when Emacs is being used intensively and there is no chance for Emacs to go on idle and perform the GC. Since GC cons threshold is raised to - \~1G (gcmh-high-cons-threshold) while Emacs is used - you will + ~1G (gcmh-high-cons-threshold) while Emacs is used - you will face a really bad hang (seconds to tens of seconds regularly). Ends up not helping much, recommend increasing gc-cons-percentage=0.2 or so instead. - Q: - A: - Q: Is there some way to free up memory (such as via - \`unload-feature\`) in Emacs? Often I only need a package loaded for + `unload-feature`) in Emacs? Often I only need a package loaded for a single task/short period but it persists in memory afterwards. - A: <https://elpa.gnu.org/packages/memory-usage.html>, and built-in M-x memory-report - most of the time, it is some history/cache variables of large buffers that are occupying memory. The library code itself is rarely affecting GC. (The other question is when libraries add timers/heavy mode-line - constructs/post-command-hooks/etc - that\'s indeed a problem, + constructs/post-command-hooks/etc - that's indeed a problem, but solved by disabling or not using a package; no need to unload) - Q: Very nice presentation! I just experimented with the threshold @@ -94,7 +94,7 @@ https://yhetil.org/emacs-devel/87v8j6t3i9.fsf@localhost/ - A: []{.underline} [[https://feh.finalrewind.org/]{.underline}](https://feh.finalrewind.org/) - Q: What was the final point you were making regarding Emacs 30? You - got cut off\... + got cut off... - A: M-x malloc-trim - Q: With 16-32G RAMs a minimal OS swapping, how about systematically doing this temporary deferral @yantar92 suggested and leave it down for a longer GC at night and whatnot? Or would cons/allocation also degrade too noticeably? - Not the speaker: That would cause Emacs to use a lot more total memory @@ -114,9 +114,9 @@ https://yhetil.org/emacs-devel/87v8j6t3i9.fsf@localhost/ summarizing the results are the answer to that request. - Now, we can continue the discussion on emacs-devel with real data at hand :) - - I hope to push for a temporary bump of \`gc-cons-threshold\' + - I hope to push for a temporary bump of `gc-cons-threshold' during Emacs init and possibly for increasing - \`gc-cons-percentage\'. + `gc-cons-percentage'. - Came for clear-cut magic bullet answers, left with nuanced analysis - and that, surprise, Eli was overall right? Now what to do with that viral gc init snippet that I've never taken time to measure myself but keep anyway... - A: I do believe that temporarily raising thresholds is ok for init time. that's the only clear-cut conclusion, unortunately - Thanks yantar92, both for the detailed investigation and exposition. I've been deferring to much-smarter-than-me Henrik for my default position (Doom has it in it's init), for lack for doing any measurements myself. |