Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: High CPU usage recording macros #864

Closed
4 tasks done
blarz opened this issue Oct 7, 2024 · 5 comments · Fixed by #860
Closed
4 tasks done

bug: High CPU usage recording macros #864

blarz opened this issue Oct 7, 2024 · 5 comments · Fixed by #860
Labels
bug Something isn't working

Comments

@blarz
Copy link

blarz commented Oct 7, 2024

Did you check docs and existing issues?

  • I have read all the which-key.nvim docs
  • I have updated the plugin to the latest version before submitting this issue
  • I have searched the existing issues of which-key.nvim
  • I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.10.2

Operating system/version

Ubuntu 22.04.

Describe the bug

By accident I left a neovim instance open where there was a macro recording session still running (classic qq I guess). I noticed the CPU fan was spinning and then checked top confirming that nvim --embed was running at 100% CPU. Hitting q to stop the recording got the CPU usage back to normal.

Bisecting my neovim config I found out that this issue only occurs with the which-key plugin loaded.

Seeing that there was some work done in that are, e.g. #851, maybe there are some issues left there?

Steps To Reproduce

  1. Open any file nvim foo.txt
  2. Start a macro recording, e.g. qq
  3. Watch CPU usage of the nvim process go to 100%
  4. Stop recording with q
  5. CPU usage goes back to normal

Expected Behavior

Regular CPU usage

Health

No response

Log

No response

Repro

No response

@blarz blarz added the bug Something isn't working label Oct 7, 2024
@theTastyWizard
Copy link

I have the same bug, just noticed it last week before updating to 10.2. 100% cpu core usage when recording macro, but using a clean install of nvim it goes down to 5%

whitestarrain added a commit to whitestarrain/dotfiles that referenced this issue Oct 9, 2024
High CPU usage recording macros.
issue: folke/which-key.nvim#864
@blarz
Copy link
Author

blarz commented Oct 9, 2024

Had a look around in the code today and in the commit 6b023b4, fixing an issue with macros and which-key, it looks like an "infinite recursion", or busy waiting loop calling M.schedule() (wrapped in a timer though), until macro recording is finished:

function M.schedule(mode)
if mode then
M.suspended[mode] = true
end
M.timer:start(
0,
0,
vim.schedule_wrap(function()
if Util.in_macro() then
return M.schedule()
end

Maybe I understand the code wrong and I am not sure if that was intended, or if there is a better way, but it would explain the CPU usage.

@blarz
Copy link
Author

blarz commented Oct 9, 2024

According to LazyVim/LazyVim#4553 folke is on vacation until the end of the month 🌴

whitestarrain added a commit to whitestarrain/dotfiles that referenced this issue Oct 21, 2024
High CPU usage recording macros.
issue: folke/which-key.nvim#864
@blarz
Copy link
Author

blarz commented Nov 6, 2024

Obligatory XKCD 😅

But seriously, is this M.schedule() loop actually needed? I tried the plugin without that line, or rather just a return and I could record macros without high CPU usage and the issue with the double recorded characters also didn't happen.

But then again I don't know the codebase at all, so I am not sure what purpose that line serves.

@blarz
Copy link
Author

blarz commented Nov 6, 2024

Awesome, thank you! 🚀

folke pushed a commit that referenced this issue Nov 28, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
🤖 I have created a release *beep* *boop*
---


##
[3.14.0](v3.13.3...v3.14.0)
(2024-11-28)


### Features

* **icons:** add grapple icon
([#838](#838))
([c21b71f](c21b71f))


### Bug Fixes

* **state:** use redraw flush to prevent issues with selecting visual
line etc. Fixes
[#898](#898)
([3974c2d](3974c2d))
* **triggers:** when in macro defer re-checking suspended for 100ms.
Fixes [#864](#864)
([f46556b](f46556b))


### Performance Improvements

* **state:** only redraw when waiting for a key longer than 200ms
([1c5aeba](1c5aeba))
* **tree:** small perf optims
([5610eb6](5610eb6))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants