spacemacs
spacemacs copied to clipboard
emacs eats cpu 100% frequently
Description :octocat:
emacs hoge cpu 100% frequently even It is idle.
Reproduction guide :beetle:
- start emacs
- open any file
Observed behaviour: :eyes: :broken_heart: emacs got freeze, can not input or move。Both happened on terminal emacs and graphic.
(%LAST_KEYS%) %SYSTEM_INFO%
- OS: gnu/linux
- Emacs: 25.2.1
- Spacemacs: 0.200.9
Backtrace :paw_prints:
- timer-event-handler 8765 73%
- apply 8761 73%
+ savehist-autosave 7504 63%
+ linum-update-current 1153 9%
+ which-key--update 60 0%
+ #<compiled 0x285199> 36 0%
+ auto-revert-buffers 5 0%
+ show-paren-function 2 0%
+ which-func-update 1 0%
cancel-timer-internal 4 0%
+ redisplay_internal (C function) 1548 13%
+ ... 894 7%
+ command-execute 625 5%
+ which-key--hide-popup 15 0%
+ evil--jump-hook 11 0%
+ evil-repeat-pre-hook 10 0%
+ evil-repeat-post-hook 7 0%
+ hl-paren-initiate-highlight 7 0%
+ winner-save-old-configurations 4 0%
company-post-command 4 0%
internal-timer-start-idle 3 0%
+ yas--post-command-handler 3 0%
And I have repeated using the profiler to track the cpu usage, the main reason leading this is savehist-autosave.
Same problem here. CPU goes to 100% even when idle. (I think it started after system update - acrh linux parabola, although I've configured my spacemacs a little bit also - I've enabled gnus) Spacemacs lags so frequently I can not even scroll 20 lines - I have to wait a few seconds.
My emacs version is 25.2.1 and spacemacs is 0.200.9 I have quite many layers enabled: nginx, php, clojure, html, emacs-lisp, git, markdown, org, gnus, python, javascript, scheme.
- timer-event-handler 27369 87%`
- apply 27369 87%`
- savehist-autosave 27124 86%
- savehist-save 27054 86%
#<compiled 0x15e2f07> 19 0%
+ sp-show--pair-function 110 0%
+ which-key--update 45 0%
+ #<compiled 0x2874cb> 41 0%
+ hl-paren-highlight 28 0%
jit-lock-context-fontify 3 0%
+ ... 2545 8%
+ command-execute 1001 3%
+ redisplay_internal (C function) 230 0%
+ eldoc-pre-command-refresh-echo-area 33 0%
+ evil-repeat-post-hook 7 0%
+ sp--save-pre-command-state 6 0%
+ winner-save-old-configurations 4 0%
+ which-key--hide-popup 4 0%
company-post-command 3 0%
+ evil-repeat-pre-hook 2 0%`
Having similar issues. It seems to getting worse as time goes on. For smaller edits i have been forced to fallback to vim. 😢
to let emacs work normally, have to disable the savehist-mode.
I also had to disable savehist-mode although it was hard, since my spacemacs starts lagging extensively before it even loads everything. And if I put (savehist-mode nil) into .spacemacs nothing happens.
After some searching I found this topic o n stackexchange: https://emacs.stackexchange.com/questions/12086/abnormally-large-savehist-file
I ran
> grep -E -b -o -a '^\(setq [[:lower:][:digit:]]+[-[:lower:][:digit:]]*' ~/.emacs.d/.cache savehist.bak
and I got
120:(setq savehist-minibuffer-history-variables
747:(setq read-expression-history
827:(setq w3m-input-url-history
1235:(setq org-refile-history
1409:(setq search-ring
1547:(setq cider-minibuffer-history
1614:(setq query-replace-history
1665:(setq magit-revision-history
1714:(setq file-name-history
8041:(setq cider-host-history
8082:(setq helm-ag--helm-history
8137:(setq rudel-tcp-ask-connect-info-host-history
8199:(setq rudel-read-user-name-history
8244:(setq rudel-tls-ask-connect-info-host-history
8332:(setq org-read-date-history
8370:(setq extended-command-history
9413:(setq ido-file-history
9734:(setq org-tags-history
10332:(setq shell-command-history
10416:(setq helm-
15313:(setq minibuffer-history
287896440:(setq ido-buffer-history
287900083:(setq evil-jumps-history
287900430:(setq mark-ring
287900452:(setq global-mark-ring
287900481:(setq search-ring
287900619:(setq regexp-search-ring
287900650:(setq extended-command-history
So it is definetly something with savehist ... This is from the savehist file:
(face org-block-begin-line font-lock-multiline t font-lock-fontified t wrap-prefix #(" " 0 6
(wrap-prefix #(" " 0 6 (wrap-prefix #(" " 0 6 (wrap-prefix " " fontified t)) fontified t))
fontified t)) fontified t) 6 7 (face org-block-begin-line font-lock-multiline t font-lock-fontified t
fontified t)) fontified t) 6 7 (face org-block-begin-line font-lock-multiline t wrap-prefix #("
#" 0 6 (face org-block-begin-line font-lock-multiline t font-lock-fontified t wrap-prefix #(" "
0 6 (wrap-prefix #(" " 0 6 (wrap-prefix #(" " 0 6 (wrap-prefix " " fontified t)) fontified t))
fontified t)) fontified t) 6 7 (face org-block-begin-line font-lock-multiline t font-lock-fontified t
fontified t)) font-lock-fontified t fontified t)) font-lock-fontified t fontified t)) font-lock-fontified t
fontified t)) font-lock-fontified t fontified t)) fontified t) 6 7
(face org-block-begin-line font-lock-multiline t wrap-prefix #(" #" 0 6
(face org-block-begin-line font-lock-multiline t font-lock-fontified t wrap-prefix #(" #" 0 6
(face org-block-begin-line font-lock-multiline t font-lock-fontified t wrap-prefix #("
There are patterns here ...
so can anyone help figure out what happens with the savehist-mode. @ivangrozni
Does the fix from the emacs stackexchange page work for you?
(setq history-length 100)
(put 'minibuffer-history 'history-length 50)
(put 'evil-ex-history 'history-length 50)
(put 'kill-ring 'history-length 25)
Maybe savehist is just missing a limit.
It (probably) solves my issue. I pasted these lines into my userconfig in dotspacemacs and now I don't have to disable savehist-mode
. Not sure why it happened in the first place.
sorry for the late reply, I have tried too, however it does not work, emacs got freeze when savehist-mode being enabled.
Hi, What is the final suggested solutions for this issue?
Is this the following solution suggested by @sdwolfz ?
(setq history-length 100)
(put 'minibuffer-history 'history-length 50)
(put 'evil-ex-history 'history-length 50)
(put 'kill-ring 'history-length 25)
That workaround doesn't work here.
@philn "here" isn't much to go by 😄
Could anyone that has this issue include your system info (press SPC h d s
to copy it to your clipboard). That might help with finding a common configuration where the issue occurs.
Yeah, sorry :)
My issue is a bit different actually, it's a racy infinite loop starving the CPU when I use the kill-ring... Unfortunately I don't know how to debug this myself. When it happens I have to kill -9
the unresponsive emacs process.
- timer-event-handler 8,556,775,181 99%
- apply 8,556,775,181 99%
- savehist-autosave 8,556,743,095 99%
- savehist-save 8,556,426,575 99%
+ savehist-printable 27,360 0%
called-interactively-p 1,461 0%
read 1,449 0%
prin1 1,449 0%
generate-new-buffer 1,061 0%
+ run-hooks 298 0%
+ #<compiled 0x1ffec3> 25,984 0%
+ auto-revert-buffers 6,102 0%
+ command-execute 53,507,069 0%
- linum-update-current 12,719,958 0%
+ linum-update 12,714,678 0%
+ flyspell-post-command-hook 1,886,745 0%
+ redisplay_internal (C function) 1,367,747 0%
+ direnv--maybe-update-environment 276,508 0%
+ winner-save-old-configurations 80,960 0%
+ evil-escape-pre-command-hook 54,272 0%
+ xselect-convert-to-string 43,938 0%
+ evil-mode-check-buffers 40,948 0%
+ xselect-convert-to-targets 16,544 0%
+ evil-repeat-pre-hook 4,136 0%
+ global-linum-mode-check-buffers 4,096 0%
... 0 0%
- timer-event-handler 19105 76%
- apply 19105 76%
- savehist-autosave 19095 76%
+ savehist-save 19010 76%
+ #<compiled 0x1ffec3> 3 0%
+ ... 4908 19%
+ linum-update-current 535 2%
- command-execute 200 0%
+ call-interactively 200 0%
+ redisplay_internal (C function) 110 0%
+ flyspell-post-command-hook 104 0%
+ evil-repeat-post-hook 3 0%
- global-hl-line-maybe-unhighlight 2 0%
+ mapc 1 0%
- direnv--maybe-update-environment 1 0%
direnv--directory 1 0%
+ evil--jump-hook 1 0%
global-visual-line-mode-check-buffers 1 0%
+ global-hl-line-highlight 1 0%
+ evil-mode-check-buffers 1 0%
+ evil-repeat-pre-hook 1 0%
System Info :computer:
- OS: gnu/linux
- Emacs: 26.3
- Spacemacs: 0.200.13
- Spacemacs branch: master (rev. 26b8fe0c3)
- Graphic display: t
- Distribution: spacemacs-base
- Editing style: vim
- Completion: helm
- Layers:
(sql ruby python typescript docker php nginx javascript html csv markdown
(lsp :variables default-nix-wrapper
(lambda
(args)
(append
(append
(list "nix-shell" "-I" "." "--command")
(list
(mapconcat 'identity args " ")))
(list
(nix-current-sandbox))))
lsp-haskell-process-wrapper-function default-nix-wrapper)
yaml ranger auto-completion emacs-lisp git helm spell-checking syntax-checking
(version-control :variables version-control-diff-tool 'diff-hl version-control-diff-side 'left))
- System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD
Here is something potentially worth investigating: https://emacs.stackexchange.com/questions/12086/abnormally-large-savehist-file
This issue occurred for me "seemingly" out of nowhere - but once it started it remained persistent.
After deleting the ~/.emacs.d/.cache/savehist
file all my issues have gone away, infact I've noticed an huge difference in general responsiveness.
Indeed this file was over 500mb in my case.
Hopefully this solves the issue for others!
This is what I have to deal with it:
;; https://github.com/syl20bnr/spacemacs/issues/9409 ;; the issue could be that save-interprogram-paste-before-kill means a large clipboard which becomes part of savehist: ;; https://github.com/syl20bnr/spacemacs/issues/1369#issuecomment-109001710 (setq history-length 100) (put 'minibuffer-history 'history-length 50) (put 'evil-ex-history 'history-length 50) (put 'kill-ring 'history-length 25) (savehist-mode -1)
@chrissound Thanks! It works for me also, my savehist file is ~170mb. Have to exit emacs before deleting the ~/.emacs.d/.cache/savehist
file.
In my case my savehist
ballooned to 1.6GB from 80kB as PNG data somehow got into the kill ring while editing an org file:
I am not sure why. I don't believe there are any images linked from the file, I may have had image data in the clipboard from GIMP, however. I can dig further if is likely to prove fruitful!
System info, although I have since updated since the issue occurred:
System Info :computer:
- OS: gnu/linux
- Emacs: 28.2
- Spacemacs: 0.999.0
- Spacemacs branch: nil (rev. a529b0bfa)
- Graphic display: t
- Running in daemon: nil
- Distribution: spacemacs
- Editing style: vim
- Completion: helm
- Layers:
(javascript
(python :variables python-test-runner 'pytest)
auto-completion emacs-lisp git helm markdown multiple-cursors org syntax-checking treemacs pdf)
- System configuration features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB
@bertiebaggio same issue here. A ~/.emacs.d/.cache/savehist file of 80 MB. Seemingly after working in org-mode, but not 100 % sure.
After working for a while in a 20k words document in org-mode I see the savehist
growing quickly. It is full of lines with 10k characters containing nested statements with parts of text and nested yank-handler
, isearch-open-invisible-temporary
, org-fold-core--isearch-show-temporary
and others. Like ("zijn " 0 1 (ws-butler-chg delete isearch-open-invisible-temporary org-fold-core--isearch-show-temporary isearch-open-invisible org-fold-core--isearch-show fontified t) 1 5 (isearch-open-invisible-temporary org-fold-core--isearch-show-temporary isearch-open-invisible org-fold-core--isearch-show fontified t))
, but then going on for 10k characters... This quickly increases the file size of the savehist file.
Interesting piece of history: kill-ring
was removed earlier from save-hist due to performance issues (https://github.com/syl20bnr/spacemacs/issues/1369#issuecomment-109158929) but it was re-added a while ago (https://github.com/syl20bnr/spacemacs/pull/14324). Maybe #14324 should be reverted.
Or better: We should try removing font properties from kill-ring: https://emacs.stackexchange.com/questions/4187/strip-text-properties-in-
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!