1

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?

4
  • Does it happens also for short files? Typically, the syntax highlighter can be slow for big files.
    – peterh
    Jan 18, 2018 at 12:54
  • Good point! Files that are not .js open instantly Jan 18, 2018 at 13:30
  • Then don't use such big files, or turn off somehow the syntax highlighter for them :-)
    – peterh
    Jan 18, 2018 at 13:31
  • remove plugins from your vimrc, half at a time until the performance improves. continue until the worst plugins are identified.
    – Mass
    Oct 7, 2021 at 23:52

2 Answers 2

0

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.

0

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.)

  1. (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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.