search

io12 / good-scroll.el

Attempt at good pixel-based smooth scrolling in Emacs
MIT License
197 stars 7 forks source link

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

Open bk138 opened 2 years ago

bk138 commented 2 years ago

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 commented 2 years ago

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

bk138 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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:

bk138 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

jwijenbergh commented 1 year ago

@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 commented 1 year ago

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 :sweat_smile: