How to see which plugins are making Vim slow?


Debugging Problem Overview

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:

Debugging Solutions

Solution 1 - Debugging

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.

Solution 2 - Debugging

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.

Solution 3 - Debugging

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

Solution 4 - Debugging

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.

Solution 5 - Debugging

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.

Solution 6 - Debugging

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.


All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestioncharlaxView Question on Stackoverflow
Solution 1 - DebuggingZyXView Answer on Stackoverflow
Solution 2 - DebuggingfeihuView Answer on Stackoverflow
Solution 3 - DebuggingIngo KarkatView Answer on Stackoverflow
Solution 4 - DebuggingPrince GoulashView Answer on Stackoverflow
Solution 5 - Debugginguser149341View Answer on Stackoverflow
Solution 6 - DebuggingRaffiView Answer on Stackoverflow