Analyze NeoVim Performance Bottlenecks

Question

My Vim is kinda slow for nearly everything. Opening a file takes five seconds, it flickers when I move up and down NerdTree and sometimes when I switch windows or tabs, it freezes for dozens of seconds.

I have a lot of plugins enabled, plus webpack watch running. I have htop running on a separate monitor, and sometimes the 4 CPUs go 100% when I save a file(that's because of webpack), so this bottleneck is understandable.

But the others cited above are not. How do I get to know what exactly is causing these bottlenecks in my Vim? Is there a way to know this without experimenting disabling plugins, etc?

Answer 1

Yes: run vim --startuptime profile and work for a bit. (To purely measure time from "enter" to "open and ready", use vim --startuptime profile +q.)

I used this and a single command quite successfully to cut my startup time by 1/3rd.

1. First, I collected the profile, as shown above.
2. Then I "analyzed" it by putting the slowest bits at the top:

:/VIM STARTING/,$ sort! f /  [^ ]*  /

(Handy trick: put :command StartupAnalyze /VIM STARTING/,$ sort! f / [^ ]* / in your vimrc and you won't have to remember how to write the command next time.)

3. (This part is specific to me) I found out that, of the nearly 300ms it took my vim to start on my laptop, 100ms were just from :runtime ftplugin/man.vim (to access :Man) and another 100ms were from a poorly designed plugin script I had. I refactored the script and changed my :runtime command to hotload the :Man command like

command -nargs=+ -complete=shellcmd Man delcommand Man | runtime ftplugin/man.vim | <mods>Man <args>

and suddenly I was averaging 100ms startup: everything felt snappier. (My other similar laptop averages 200ms with the same setup, so some machine variability is expected.)

---

Others have recommended tuning down the amount of plugins you have installed. This is certainly one way to reduce your bottlenecks! But, for the record, I have 72 plugins installed. The reason vim starts up so fast is that most of them are using autoload effectively; defining a handful of commands or mappings is pretty fast. Of course, startup time is not the same as everyday bottlenecks. For that, I would consider using more vim9 or more lua, as the case may be. I would also second removing plugins: some you probably just don't need; you could find a way to work differently and get rid of some of the bloat; or you could implement smaller versions that do only what you need.

---

You mention .js files specifically. Try vim --startuptime profile <your-slow-js-file> +q, or even leave it running and quit later. Analyze that. See what's taking so long to load. Syntax? A synchronous LSP that should really be async? Some plugin that's doing too much? If other files are snappy, then this indicates the problem lies here.

For what it's worth, I had the same problem with markdown files—they were orders of magnitude slower than other types of files. I was able to track down that markdown files spent lots of time sourcing all the included syntax definitions (useful for having syntax highlighting inside triple-backtick blocks). I had about 8 languages in the "support triple-backtick" configuration; removing those entirely sped up editing markdown files significantly, and now I just live with the fact that I don't have syntax highlighting in those little blocks.

Answer 2

One plugin that notably improved my neovim startup time is filetype.nvim the speed test measured 175x faster filetype detection for neovim.

This plugin is a replacement for the included filetype.vim that is sourced on startup. The purpose of that file is to create a series of autocommands that set the filetype variable depending on the filename. The issue is that creating autocommands have significant overhead, and creating 800+ of them as filetype.vim does is a very inefficient way to get the job done.