emenel/doomemacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

perf: run GC a little less aggressively

Browse source 
The delay will not be adjusted on a per-GC basis, depending on its last
run-time. This should average to around 2-3s, which should be a good
compromise between GCing too often and too infrequently.
This commit is contained in:
Henrik Lissner 2021-10-09 17:13:54 +02:00
parent 68d8364aea
commit 6bd9c7c880
1 changed files with 6 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

10
core/core.el
View file

@ -310,10 +310,12 @@ config.el instead."
;; The GC introduces annoying pauses and stuttering into our Emacs experience, ;; The GC introduces annoying pauses and stuttering into our Emacs experience,
;; so we use `gcmh' to stave off the GC while we're using Emacs, and provoke it ;; so we use `gcmh' to stave off the GC while we're using Emacs, and provoke it
;; when it's idle. ;; when it's idle. However, if the idle delay is too long, we run the risk of
(setq gcmh-idle-delay 0.5 ; default is 15s ;; runaway memory usage in busy sessions. If it's too low, then we may as well
gcmh-high-cons-threshold (* 16 1024 1024) ; 16mb ;; not be using gcmh at all.
gcmh-verbose doom-debug-p) (setq gcmh-idle-delay 'auto ; default is 15s
gcmh-auto-idle-delay-factor 10
gcmh-high-cons-threshold (* 16 1024 1024)) ; 16mb
;; Emacs "updates" its ui more often than it needs to, so slow it down slightly ;; Emacs "updates" its ui more often than it needs to, so slow it down slightly
(setq idle-update-delay 1.0) ; default is 0.5 (setq idle-update-delay 1.0) ; default is 0.5