High CPU when using display-line-numbers-mode on Emacs 28.1
Opened this issue · 11 comments
Describe the bug
When running good-scroll-mode together with display-line-numbers-mode, the CPU usage goes up to ~10% to 15% on my 2.6GHz CPU using Emacs 28.1 with native-comp. The window with the line numbers has to be active to see the behaviour. If I switch to another window after C-x 2 the CPU usage goes down. Giving focus to the window with line numbers: higher CPU again.
To Reproduce
Steps to reproduce the behavior:
- use the following ready-to-start (uses use-package) .emacs I prepared:
(require 'package)
(setq package-enable-at-startup nil)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
(if (string-equal system-type "gnu/linux")
(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")) ; make default https elpa usable again
(package-initialize)
(unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package))
;; configure use-package
(eval-when-compile
(require 'use-package)
(setq use-package-compute-statistics t)
(require 'use-package-ensure)
(setq use-package-always-ensure t))
(use-package good-scroll
:config (good-scroll-mode 1))
(global-display-line-numbers-mode)
- open some text or source code file
- watch the CPU emacs consumes, should be quite high (for an idle text editor)
- disable display-line-numbers-mode
- watch the CPU emacs consumes, should be very low
Expected behavior
Low CPU usage with good-scroll and display-line-numbers-mode.
Videos
N/A
Version and environment
- OS: Debian 11
- Emacs version: GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2022-08-20, modified by Debian
Additional context
Uses native-comp, but I'm not sure if that matters.
I tried that, but it does not yield anything conclusive. One more thing worth mentioning is that I see that under GNOME 3.38, both Wayland and X11. The interesting thing is that gnome-shell CPU usage also goes up together with emacs when doing the mentioned repro steps. Maybe that emacs mode combination is exposing some inefficiency in gnome-shell...
This is what I get after around 50s
202 45% - timer-event-handler
202 45% - apply
202 45% + #<compiled -0x187cd7fb86125353>
138 31% - command-execute
121 27% - byte-code
121 27% - read-extended-command
78 17% - completing-read-default
5 1% + redisplay_internal (C function)
17 3% - funcall-interactively
14 3% - minibuffer-complete
14 3% - completion-in-region
14 3% - completion--in-region
14 3% + #<compiled -0xf4e010c85352e2>
3 0% - execute-extended-command
3 0% - command-execute
3 0% funcall-interactively
64 14% - redisplay_internal (C function)
43 9% - eval
18 4% - if
4 0% display-graphic-p
15 3% - unless
9 2% - if
9 2% display-graphic-p
3 0% - mode-line-default-help-echo
3 0% - window-at-side-p
3 0% window-pixel-edges
39 8% + ...
I tried out good-scroll today and just wanted to say that I also encountered issues OP described.
Emacs' cpu usage:
~4% without the package
~20% without line numbers
~50% with line numbers
(on a 3.2 GHz cpu)
Profiler for 1 min:
1062 52% - command-execute
1058 52% - byte-code
1058 52% - read-extended-command
1058 52% - completing-read-default
1058 52% - apply
1058 52% - vertico--advice
205 10% + #<subr completing-read-default>
4 0% + funcall-interactively
783 38% - ...
783 38% Automatic GC
170 8% + redisplay_internal (C function)
Setup:
- Doom emacs 28.2.50
--with-native-compilation --with-pgtkfrom https://aur.archlinux.org/packages/emacs-gcc-wayland-devel-bin- Arch linux
- Sway (wayland)
@ericliou thanks for reporting as well! Could you also be so kind and try with the minimal config I posted so we have comparable results?
I ran a fresh vanilla emacs with that config and this is the result:
~20% cpu with the above config
~2% cpu with (global-display-line-numbers-mode) removed
650 74% - command-execute
644 73% - byte-code
644 73% - read-extended-command
26 2% + completing-read-default
6 0% + funcall-interactively
129 14% + ...
78 8% + timer-event-handler
18 2% + redisplay_internal (C function)
Hm interesting. I also wonder why doom makes the issue worse than in vanilla.
I ran a fresh vanilla emacs with that config and this is the result: ~20% cpu with the above config ~2% cpu with
(global-display-line-numbers-mode)removed650 74% - command-execute 644 73% - byte-code 644 73% - read-extended-command 26 2% + completing-read-default 6 0% + funcall-interactively 129 14% + ... 78 8% + timer-event-handler 18 2% + redisplay_internal (C function)Hm interesting. I also wonder why doom makes the issue worse than in vanilla.
can you confirm this does not happen (or less severe) without pgtk (so with an emacs that does not have the --with-pgtk flag)
@jwijenbergh I've updated the emacs version in the top post. It's not pgtk in my case.
@jwijenbergh I've updated the emacs version in the top post. It's not pgtk in my case.
Ok thanks! I thought pgtk might be part of the problem, but I guess not then
In the last weeks or months I noticed Emacs was using 30%+ CPU at rest but never took the time to investigate.
Today I finally investigated by gradually commenting out parts of my conf, and I finally identified the root cause is good-scroll-mode, hence I found this issue. I just want to add my voice to the choir, the performance problem is real 😅
Just leaving a note that something that stresses a lot good-scroll is the *sly-inspector* buffer for the common lisp development tool.