High CPU when using display-line-numbers-mode on Emacs 28.1

[bk138]

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:

1. 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)

2. open some text or source code file
3. watch the CPU emacs consumes, should be quite high (for an idle text editor)
4. disable display-line-numbers-mode
5. 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.

[io12]

I can't reproduce this. Can you use a profiler to see what's using so much CPU?

[bk138]

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...

[bk138]

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% + ...

[ericliou]

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-pgtk from https://aur.archlinux.org/packages/emacs-gcc-wayland-devel-bin
• Arch linux
• Sway (wayland)

[bk138]

@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?

[ericliou]

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.

[jwijenbergh]

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.

can you confirm this does not happen (or less severe) without pgtk (so with an emacs that does not have the --with-pgtk flag)

[bk138]

@jwijenbergh I've updated the emacs version in the top post. It's not pgtk in my case.

[jwijenbergh]

@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

[sir4ur0n]

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 😅

[azimut]

Just leaving a note that something that stresses a lot good-scroll is the *sly-inspector* buffer for the common lisp development tool.