search

AstroNvim / AstroNvim

AstroNvim is an aesthetic and feature-rich neovim config that is extensible and easy to use with a great set of plugins
https://AstroNvim.com
GNU General Public License v3.0
12.74k stars 926 forks source link

Latest updates causing extremely slow UI. #2676

Closed kevinkirkup closed 1 month ago

kevinkirkup commented 3 months ago

Checklist

Operating system/version

macOS 14.5

Terminal/GUI

kitty

AstroNvim Health

============================================================================== astronvim: require("astronvim.health").check()

AstroNvim ~

Describe the bug

After launch nVIM, the use is fine but slow gets slower and slower. Updating Astro doesn't fix the issue and perhaps, makes it worse. The only solution to to restart the entire nVim instance.

Steps to Reproduce

  1. Open nVIM with Astro
  2. Open 20 files
  3. Close 19 files
  4. Update Astro :AstroUpdate
  5. Repeat

Expected behavior

nVim should be snappy

Screenshots

No response

Additional Context

No response

Repro

-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  -- stylua: ignore
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", "--branch=stable", lazypath })
end
vim.opt.rtp:prepend(vim.env.LAZY or lazypath)

-- install plugins
local plugins = {
  { "AstroNvim/AstroNvim", import = "astronvim.plugins" },

  -- add any other plugins/customizations here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

-- add anything else here (autocommands, vim.filetype, etc.)
mehalter commented 3 months ago

Given then information I cannot replicate. I have opened 100 files and don't have any significant slowdown. This could be related to plugins that you have or even things like language servers doing a lot of work or something.

One note is running :AstroUpdate or :Lazy update without a restart will definitely not improve performance at all. It's very much recommended to restart entirely after update.

jsco2t commented 3 months ago

I'm seeing the same issue on my install. Attempting to edit:

Results in a UI which is incredibly slow to navigate. Everything seems to grind to a halt. Scrolling/Navigating up and down a screen of code is particularity slow and laggy. Watching btop I can see a significant (significant being contextual to the hardware being used) spike in CPU usage.

My nvim version info is:

NVIM v0.10.1-dev-101+g18a9ae169
Build type: RelWithDebInfo
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info

What's the best way to turn this issue report into something actionable? Is there any sort of telemetry/profiling/observability tooling that can be run which will help pin-point the problem?

A couple more items of note:

  1. I didn't make any changes to my setup other than running :AstroUpdate.
  2. I always close and re-open nvim after updating plugins

Lastly - I'm wondering if the hardware being used may contribute to how observable this issue is? I have my nvim setup in a VM (been this way for a while) and it's setup to use 2 virtual CPU's (@ 2.3Ghz). Previously this hasn't been an issue.

I'm a huge fan of the work that the AstroNvim team (and Neovim team) does - so if there is something I can do to help investigate please let me know.

mehalter commented 3 months ago

I'm honestly not sure. All of my performance testing involves throttling my CPU and testing on extremely low power and decreased cores just so I can emulate low resource and/or older hardware. Not sure the best way of debugging this outside of maybe bisecting the AstroNvim repo to see if you can pin point a commit where the performance gets worse

jsco2t commented 3 months ago

Thanks @mehalter

Let me try killing some plugins and see what happens. Also - I was wrong above. Editing lua files actually seems OK. IF I wait for the Lua Language Server to idle back down. When it loads it's busy for a bit before settling back down. If I wait it out (again watching btop) then the editing experience is OK.

mehalter commented 3 months ago

Nice. Yeah it is possible that it's language server related and if that's the case it's sorta out of scope from us to be able to fix in any way

jsco2t commented 3 months ago

Totally get that.

For Go I think something else is in the mix. As I wait for gopls to go idle before attempting to use things and the editing experience is "not great".

kevinkirkup commented 3 months ago

Just a heads up: Noticed these messages may be related: No LSP client found that supports symbols in buffer 31

mehalter commented 3 months ago

@kevinkirkup nearly 100% isn't related. That is an Aerial bug: https://github.com/stevearc/aerial.nvim/issues/393

But shouldn't be causing any performance issues.

kevinkirkup commented 3 months ago

@mehalter Is aerial being pulled in by Astro?

It's not a plugin that I've included in my config. I do see it in my lock file though. 🤔

mehalter commented 3 months ago

yeah it's a default plugin: https://docs.astronvim.com/reference/default_plugins/

jsco2t commented 3 months ago

@mehalter, @kevinkirkup

tl;dr In my astronvim install I have found the following two plugins appear to be having a significant impact on CPU:

return {
  { "rebelot/heirline.nvim", enabled = false },
  { "lukas-reineke/indent-blankline.nvim", enabled = false },
}

Read below for the details:

Before I discuss my results - let me discuss my methodology as I don't have concrete proof other than observed impact on CPU.

My methodology:

  1. Have btop running in a terminal window - leave this window open, but make sure it's visible.
  2. In a new terminal window: open a go source file which is part of a golang project in Astronvim
  3. Wait for gopls and it's peers to run and go idle before continuing. In other words: Wait for the CPU to idle.
  4. Scroll up and down repeatedly in Astronvim using the up/down arrow keys (or the j/k keys).
  5. Observe the CPU impact (specifically how much CPU nvim consumes)
  6. Observe (subjective) how badly the UI stutters.

Where I started today:

How I "debugged":

I would go through and shut off options in Astrovim and eventually I disabled plugins entirely until I got my CPU usage down to (close) to the numbers I observed when nvim was running with 0 plugins.

What I found was that the following two plugins seemed to be having an outsized impact on my CPU usage:

Tested by adding a file named disabled.lua into my lua/plugins folder with the following content:

return {
  { "rebelot/heirline.nvim", enabled = false },
  { "lukas-reineke/indent-blankline.nvim", enabled = false },
}

With these two plugins disabled my CPU usage would sit around 4% to 7% while actively scrolling up/down.

I understand heirline is a pretty critical part of the default Astronvim experience. For me - I am likely to need to find an alternate status line configuration. indent-blankline is very helpful to me - but I can probably live without it.

jsco2t commented 3 months ago

My configuration can be found here (the config I was using to test with) should that be helpful:

https://github.com/jsco2t/dotfiles/tree/av-perf-investigation/.config/nvim

mehalter commented 3 months ago

@jsco2t really appreciate the deep dive! This is amazing information! I'll be curious if you find that a different statusline plugin does any better, I did some benchmarking against lualine and feline and our heirline implementation is highly optimized with caching and stuff to decrease how much work it does. I see on my end that the CPU usage is less than when using those statusline plugins. indent-blankline definitely will be pretty intensive

jsco2t commented 3 months ago

@mehalter

As it happens I played a lot with this last night. I ended up using heirline but customized it slightly to remove some of the components that were updated on cursor movement. The performance is now completely acceptable (as long as I also leave indent-blankline.nvim disabled).

Here is a copy of the configuration I used for heirline (it's based on what's in the Astronvim Docs - amazing work whoever put those together): https://github.com/jsco2t/dotfiles/blob/main/.config/nvim/lua/plugins/statusline.lua

8tomat8 commented 2 months ago

@jsco2t This solved it for me. Thanks! Initially I was blaming the poor performance on neo-tree plugin as with open file tree I would get extremely bad performance (e.g. easily 5sec switching between buffers) and practically stopped using the tree. With the updated heirline config the UI is snappy as it should be. ❤️

github-actions[bot] commented 1 month ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.