Very high CPU usage with inlay hints on split windows

[SPFabGerman]

Thank you for the bug report

• [X] I am using the latest version of lsp-mode related packages.
• [X] I checked FAQ and Troubleshooting sections
• [X] You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

I recently noticed, that sometimes emacs suddenly uses almost all of my CPU (>90%) under some strange circumstances. Specificly when working with split windows when inlay hints are enabled. Such high CPU usage is not the normal case for my emacs setup. I don't know if this is relevant, but I am using the latest version of emacs (Emacs 30). I noticed this bug when working on a Rust project. I don't know if this bug also triggers under other language servers. Any help on why this happens would be very appreciated.

Steps to reproduce

I was able to create a minimal config to trigger this bug:

(scroll-bar-mode -1)
(setq inhibit-startup-message t)
(set-face-attribute 'default nil :height 120)
(require 'package)
(package-initialize)
(setq lsp-inlay-hint-enable t)
(require 'lsp-mode)

Removing any of the above lines stops the bug from triggering.

I started emacs with: emacs -q -l init-mini.el src/main.rs. As soon as emacs started I used M-x lsp to start LSP. After the rust-analyzer finished the initial setup and the inlay hints appear I run M-x split-window-horizontally to split the window horizontally and the CPU usage for emacs immediatly goes up to 90% and stays there, until the second window is closed.

I also noticed that this bug only triggers if emacs is started maximized. If emacs takes up only a part of my screen, this bug does not trigger! (As far as I can tell, only the window size before starting lsp makes a difference here. Resizing the window after lsp was started does not affect the bug.)

Expected behavior

Normal CPU usage, even when splitting the windows.

Which Language Server did you use?

rust-analyzer

OS

Linux

Error callstack

No response

Anything else?

No response

[deifactor]

t appears that something in lsp--update-inlay-hints-scroll-function is causing window-scroll-functions to be invoked again, setting up an infinite loop. I've noticed this doesn't always happen. I can't figure out a 100% consistent repro.

This is with emacs 29.

[ckruse]

Thanks to this report I was finally able to pin-point my problems.

keyboard-quit stopped working for me pretty reliably when lsp-mode was involved. I wasn't able to tell why, I had to set debug-on-signal and send USR2 to Emacs; this showed me a stack trace with lsp--update-inlay-hints-scroll-function. After looking through the issues, I found this entry and disabled inlay hints - and now I am able to use Emacs again.

Thanks a lot, it has cost me weeks to find the culprit.

[Lompik]

If one wants to keep inlay hints, setting (setq lsp-update-inlay-hints-on-scroll nil) was enough for me to get rid of the CPU hogging.

[SPFabGerman]

@Lompik Thanks for your suggestion, it does indeed get rid of the high CPU usage issue, so it is a good temporary fix. The tradeoff is of course, that the inline hints now update only after a small idle period and the resulting pop-ins of text are rather noticable and somewhat distracting. But your suggestion does not fix the underlying problem, so I will keep this issue open for now.