All talks: https://emacsconf.org/2023/talks/
emacs-gc-stats: Does garbage collection actually slow down Emacs?
https://emacsconf.org/2023/talks/gc - Ihor Radchenko - Track: Development
Watch/participate: https://emacsconf.org/2023/watch/dev/
Q&A room: https://media.emacsconf.org/2023/current/bbb-gc.html
IRC: https://chat.emacsconf.org/#/connect?join=emacsconf,emacsconf-dev or #emacsconf-dev on libera.chat network
Guidelines for conduct: https://emacsconf.org/conduct
See end of file for license (CC Attribution-ShareAlike 4.0 + GPLv3 or later)
----------------------------------------------------------------
Notes, discussions, links, feedback:
----------------------------------------------------------------
Questions and answers go here:
- 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 near 1 sec. Really varies. But the number of people 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* 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 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)). 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 creating and throwing away timers after each command (via `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 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:
- Q: Is there some way to free up memory (such as via `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, but solved by disabling or not using a package; no need to unload)
- Q: Very nice presentation! I just experimented with the threshold and lowered my gc-elapsed from 1.1 to 0.06 seconds (during startup). Interestingly, going to 10MB increased the time, 4MB was the sweet-spot for my system. What is the recommended way to lower the value back to the default value after startup is complete?
- Q:what were you using to flip through the PNGs? (thanks for the answer. look-mode on melpa does that too ;)
- Q: What was the final point you were making regarding Emacs 30? You got cut off...
- Q:
- Q:
- Q:
----------------------------------------------------------------
Next talks:
Questions/comments related to EmacsConf 2023 as a whole? https://pad.emacsconf.org/2023
----------------------------------------------------------------
This pad will be archived at https://emacsconf.org/2023/talks/gc after the conference.
Except where otherwise noted, the material on the EmacsConf pad are dual-licensed under the terms of the Creative Commons Attribution-ShareAlike 4.0 International Public License; and the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) an later version. Copies of these two licenses are included in the EmacsConf wiki repository, in the COPYING.GPL and COPYING.CC-BY-SA files (https://emacsconf.org/COPYING/)
By contributing to this pad, you agree to make your contributions available under the above licenses. You are also promising that you are the author of your changes, or that you copied them from a work in the public domain or a work released under a free license that is compatible with the above two licenses. DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION.