How to see which plugins are making Vim slow?

347
votes

Is there a way to profile Vim plugins?

My MacVim becomes slower and slower when I open a large .py. I know I could deselect all plugins and reselect one by one to check which plugin is the culprit, but is there a faster way?

My dotvim is here: https://github.com/charlax/dotvim

6
debuggingoptimizationvimmacvim
See stackoverflow.com/questions/1687799/profiling-vim-startup-time – chelmertz
Actually, startup is fine. Vim becomes slow after a few minutes of use. It especially concerns .py files. – charlax
Binary search is the way to go. You have asked your question 2 hours ago, the cause of your problem would have been found in that time. Ingo Karkat's autocmd hunch sounds the mst plausible to me. – romainl
That's true - but don't you think that if there's a way to get the same result in even one hour, that's better? What's more, startup is fine, it's after a few minutes of use, so it would have taken a very long time. autocmd looks cool. Just tried it but Vim is not slow right now. – charlax
Just faced same issue, but on big ruby files. Found that folding=syntax can slow down. Tried with folding=manual and now everything works fine – Aleksandr K.

6 Answers

549
votes

You can use built-in profiling support: after launching vim do

:profile start profile.log
:profile func *
:profile file *
" At this point do slow actions
:profile pause
:noautocmd qall!

(unlike quitting noautocmd is not really required, it just makes vim quit faster).

Note: you won’t get information about functions there were deleted before vim quit.

81
votes

I found another very helpful vim buildin method to show the exactly timing messages while loading your .vimrc.

vim --startuptime timeCost.txt timeCost.txt

Please run:

:help --startuptime

in VIM to get more information.

31
votes

It could be a plugin or the syntax highlighting; try a :syntax off when this happens and see whether Vim instantly gets faster.

With plugins, a "general slowness" usually comes from autocommands; a :autocmd lists them all. Investigate by killing some of them via :autocmd! [group] {event}. Proceed from more frequent events (i.e. CursorMoved[I]) to less frequent ones (e.g. BufWinEnter).

If you can somewhat reliably reproduce the slowness, a binary search might help: Move away half of the files in ~/.vim/plugin/, then the other, repeat in the set that was slow.

If you really need to look under the hood, get a Vim version that has the :profile command enabled. (Not the vanilla BIG Windows version, but the one that ships with Cygwin has it; also, self-compiling is quite easy under most distros.)

17
votes

I have found it helpful to print all Vim activity to a file by starting Vim with the -V option:

vim -V12log

This provides the maximum verbosity (level 12) and outputs it to the file log. You can then perform some Vim actions which you know to be slow, and then see which functions/mappings are being called internally.

8
votes

If you're having problems with screen update operations (^L, scrolling, etc) being slow, your problem may be an inefficient syntax highlighting file. You can test this by temporarily disabling syntax highlighting (:syn off) and seeing if the problem goes away; if you want to dig into the details, you can profile the current syntax file using :syntime:

  1. Open a file that causes syntax highlighting performance issues.
  2. Run :syntime on to start profiling.
  3. Scroll through the file a bit.
  4. Run :syntime report to generate a report. The patterns listed first in the report are the ones which took the most time to process.
1
votes

A very simple solution: Find one slow command. Move one plugin to /tmp/. Try the command again. If it's still slow, move another plugin to /tmp/. Repeat, until you find the plugin that makes the command slow.