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.
- First, I collected the profile, as shown above.
- 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.)
- (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.
.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.