I have a strange issue. Sometimes (not every time, but often enough) the startup is extremely slow (ten seconds or more). Most of the time, when I run vim next time, it starts reasonably fast. Then in a few minutes or hours it starts up slowly again, just once. I can never reproduce the issue at will.

I tried to profile vim with --startuptime option. Normally the output looks like this

079.057  000.613  000.468: sourcing /usr/share/vim/vim80/ftplugin/cpp.vim
209.450  136.220: opening buffers
209.540  000.090: BufEnter autocommands

but when the startup is slow, it may look like this:

077.801  000.340  000.268: sourcing /usr/share/vim/vim80/ftplugin/cpp.vim
10408.516  10333.252: opening buffers
10408.686  000.170: BufEnter autocommands

It is always the "opening buffers" line. No other action is abnormally long.

The intermittent nature of this slowness makes it very hard to debug.

What tools are at my disposal to troubleshoot the issue?

  • 1
    You could try to reproduce with vim --clean or vim -u NONE -N or vim -u DEFAULTS... if you cant, then I blame a plugin. If you can, more details will be necessary.
    – D. Ben Knoble
    Apr 22, 2020 at 12:26
  • @D.BenKnoble The problem is, when vim --clean etc doesn't reproduce the problem, I have no idea whether it's because clean runs never exhibit the problem, or because it just decided to run OK this time. But suppose it's a plugin; how do I find what part of what plugin is responsible? Apr 22, 2020 at 12:42
  • You can find which plugin is responsible by re-adding them until you observe the behavior... unfortunately the test is flaky. Priority should be to come up with a way to reproduce the behavior. 'verbose' might help
    – D. Ben Knoble
    Apr 22, 2020 at 12:47
  • @D.BenKnoble I would love to come up with a way to reproduce this reliably. I'd probably know where to go from there. I tried running with -V9verbose.log, there's nothing interesting in there. Apr 22, 2020 at 12:57
  • Only other advice i have is this plugin (github.com/dstein64/vim-startuptime) which can average lots of startuptimes together—i dont expect it to give you much new information though. I wonder if it’s syntax highlighting open buffers or editing over an ntfs or somethijg
    – D. Ben Knoble
    Apr 22, 2020 at 13:39

1 Answer 1


Run vim under strace.

Create a wrapper binary called vim in your home directory (e.g. ~/bin/vim or ~/.local/bin/vim) and make sure that directory comes first in $PATH. If you start Vim as vi or other names, create similar wrappers too.

In the contents of the wrapper script, use:

exec strace -f -tt -s 1024 -o /tmp/strace.vim.$(date +%s).$$ /usr/bin/vim ${1+"$@"}

Make sure you make the script executable, with:

$ chmod +x ~/bin/vim

Test it to make sure it works, then check that these /tmp/strace.vim.* files are being created as expected.

Next time you have a 10s delay, look at the strace files under /tmp and find the one corresponding to the invocation that had the delay (it should be the last one and they should be listed in chronological order), then see if that sheds a light into what is delaying your startup. If it's anything related to filesystems or reading or looking up files, it will probably show up there. (On the other hand, if it's an issue that is triggering the CPU to go spinning for that amount of time, that typically won't show on strace. But I think your chances are good that it will show there.)

You'll have some overhead of running Vim under strace all the time, which isn't great but I wouldn't expect it to be too painful...

Diskspace might be a problem as the strace files start to accumulate and grow in your /tmp directory. You might want to consider adding a tmpwatch configuration to prune those files somewhat aggressively to prevent them to filling up your disk. (Also consider whether /tmp is the best location on your system to store those, quite possibly a different location will work better in your system.)

Hopefully this will help you identify the root cause, or at least give you additional data points that you can use to narrow it down.

  • 1
    Thanks, I found the culprit with strace, it was a flaky NFS share that somehow got into $PATH.It takes a long time to respond depending on who knows what. Apr 26, 2020 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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