vim-startuptime turns Vim's --startuptime output into something you can read

The problem: startup cost you cannot see

vim-startuptime is a plugin for viewing vim and nvim startup event timing information, and the whole premise is that this information already exists but nobody looks at it.

Vim and Neovim both accept a --startuptime argument, and when you pass it the editor records a timestamped line for each startup event: the moment the file was sourced, how long that took, and the cumulative time up to that point. That log is exactly what you need when a plugin manager has noticeably slowed down startup, and exactly what most people never see, because it is written to a file and the editor carries on as if nothing happened.

The plugin's contribution is presentation and navigation. The README says the data is automatically obtained by launching (n)vim with the --startuptime argument, which means you do not have to construct the command line yourself or dig out a log file. The plugin does it for you and shows the result.

The audience is specific: Vim and Neovim users whose configuration has grown, and who suspect that a plugin, a syntax file or a Lua module is responsible for the delay. The topics are profiling, startup, vim and vimscript, and the primary language is Vim Script with a lua directory in the repository, so the implementation spans both ecosystems that the two editors support.

The licence is MIT, and the release history shows steady work: v4.6.1 on 2026-05-30, v4.6.0 on 2026-04-10 and v4.5.0 on 2024-02-11, with the last push on 2026-05-30 and the repository not archived.

The compile-time feature requirements

The requirements section is short and specific, and it is worth reading before you install anything.

The stated requirement is vim>=8.0.1453 or nvim>=0.3.1, and the README is careful to add that the plugin may work on earlier versions but has not been tested. That is a fair formulation, and it is the kind of note that saves an afternoon of debugging a partially working plugin.

The dependencies are compile-time features for vim, and the note says they are not applicable for nvim. There are three of them. The +startuptime feature is required, which makes sense since the entire data source depends on it. The +terminal feature is required, which is less obvious and is worth pausing on: the plugin needs a terminal buffer to render its output in.

The +timers feature is recommended rather than required, and the reason given is specific: it is needed to capture all startup events. So without it you get a partial list rather than a failure, which is a useful thing to know when you are looking at a table and wondering why some of your plugins are missing from it.

For Neovim, the equivalent of these is the built-in behaviour of the editor, and the README simply notes that the compile-time feature list does not apply. A Neovim user therefore has fewer things to check and, by the same token, no indication of which parts of the timing data are complete.

The topic list includes profiling, which is the right word for what this is. The plugin does not change startup time. It tells you where the time went.

Installing across the plugin managers

The README does not pick a single package manager. It says a package manager can be used to install vim-startuptime, and then lists the common ones with the exact command for each, which is the right approach for a plugin that has to work in configurations as varied as Vim ones.

The Vim 8 native packages route is a plain git clone into the package directory:

The command is git clone https://github.com/dstein64/vim-startuptime ~/.vim/pack/plugins/start/vim-startuptime.

The other managers use their own declaration syntax, and the README gives both the config line and the install command. For Vundle it is the Plugin declaration in ~/.vimrc followed by :PluginInstall or the shell form $ vim +PluginInstall +qall. For vim-plug it is the Plug declaration with :PlugInstall or the same shell form. For dein.vim it is the call dein#add line followed by :call dein#install(). For NeoBundle it is the NeoBundle declaration, and then you re-open vim or execute :source ~/.vimrc.

Pathogen is the odd one out because it clones with a shallow depth:

The command is git clone --depth=1 https://github.com/dstein64/vim-startuptime ~/.vim/bundle/vim-startuptime.

The depth one matters for a plugin you will update occasionally rather than develop, since a shallow clone keeps the download small.

Notice that the install command itself differs in form between managers. The PluginInstall and PlugInstall commands can be run from inside a running editor, while the dein and NeoBundle flows need their own invocation, and the git clone routes need no command at all.

Reading the table and moving around it

The usage section is four lines, and every one of them earns its place.

You launch the plugin with the :StartupTime command. You press K on events to get additional information. You press gf on sourcing events to load the corresponding file in a new split. And the key sequences can be customized, with the pointer to :help startuptime-configuration. Times are in milliseconds.

The gf mapping is the one that changes the workflow. A startup log is a list of sourced files with timings, and the question it usually provokes is which file is responsible for the expensive part. Being able to jump straight from a row in the table to the file in a new split means the investigation stays in one editor, and a plugin that loads an expensive syntax file or a slow Lua module becomes something you can open and read at the moment you notice it in the timings.

The K mapping for additional information is the other half. The table gives you the event and its duration, and the extra detail gives you what the event actually was, which for a sourcing event is the file and for other events is the operation.

The fact that the key sequences are configurable matters more than it might seem. This is a plugin that lives in the same keymap space as your editing workflow, and a plugin that hardcodes K and gf is a plugin that will collide with something else you use. The configuration topic is listed separately from the arguments and modifiers topics, so the extent of the customisation is documented rather than implied.

Documentation structure and the configuration surface

The documentation is reachable in two ways, and the README gives both. You can read it through the normal help system:

:help vim-startuptime

Or you can ask the plugin itself:

:StartupTime --help

The underlying markup lives in startuptime.txt in the doc directory, which is the standard Vim help file format, so the text is available through :help and searchable with the usual tags.

The documentation index in the README lists five topics. Arguments covers what you can pass to the command. Modifiers covers the modes the display can take. Vim Options covers the editor options that affect the measurement. Configuration covers the customisation options, which the README references earlier for the key sequences. Color Customization covers how the output is coloured.

The separate Vim Options topic is the one that tells you what affects the numbers rather than the display. Since the measurement is of the editor's own startup, anything that changes startup behaviour, such as what plugins load and in what order, changes the result, and the plugin exposing that as a documented topic is how you reason about comparing one run against another.

The repository layout is consistent with a Vim plugin written for both editors. There is an autoload directory, a doc directory, a lua directory, a plugin directory and a tests directory, plus a .luacheckrc for the Lua side, which confirms the Lua code is linted separately from the Vim Script.

Where vim-startuptime is the wrong tool

Three boundaries, and the first is the one the name invites you to get wrong.

This measures startup. It does not profile your editor while it runs, and it does not tell you which function is slow in a long-running session. A plugin that does that job needs a different mechanism, such as a sampling profiler attached to the running process, because the startup log is a record of the first few hundred milliseconds and nothing after it. If your problem is that Vim feels sluggish once you have been working for an hour, this plugin will show you a fast startup and give you no useful information.

The second is that the measurement is of a relaunched editor, not of the session you were in. The plugin obtains the data by launching the editor with the --startuptime argument, so what you are reading describes a fresh start with your configuration, not the state you were in when you ran the command. That is the right thing to measure for plugin cost, and it also means the run will include whatever your configuration does on load, including anything that depends on a session or a buffer you had open. Running it from a clean environment tells you about the configuration, and running it with your usual session loaded tells you about the configuration plus your session.

The third is the feature dependency, which is real for Vim builds. A minimal or compiled-down Vim without +terminal will not run this at all, and a build without +timers will show you an incomplete list without telling you it is incomplete. The README flags both, but a plugin that reports a confident-looking table with rows missing is the kind of thing that sends you chasing the wrong file for an afternoon.

The alternative approach, for a broader performance question, is a general purpose profiler attached to the editor process, which gives you a much wider view at the cost of not knowing which plugin or file is responsible for the specific line in a startup log. The difference in approach is that this plugin is a specialised reader of one specific editor feature, and that is exactly why it is useful: the data is already structured, already per-file, and already in the order the editor loaded them, which is information a sampling profiler would give you only after you had worked out which of its samples belonged to which plugin.

Editorial conclusion

Adopt vim-startuptime if your Vim or Neovim startup feels slow and you need to know which plugin, script or source file is responsible, since it surfaces the editor's own --startuptime output in a table you can navigate rather than a raw log. Do not adopt it to measure runtime performance in general, because it covers startup only, and do not expect it to work on an editor without the +startuptime and +terminal features it depends on, and know that without +timers the event list may be incomplete. Verify first that your editor satisfies the stated requirement of vim>=8.0.1453 or nvim>=0.3.1, that +startuptime and +terminal are present in your build, and that you understand the plugin relaunches the editor, which means your session state is not the one being measured until you are inside the new instance.

Frequently asked questions

Official sources

1. dstein64/vim-startuptime on GitHub
2. Issues
3. License: MIT
4. README
5. Releases