368

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

Teun Zengerink
  • 4,277
  • 5
  • 30
  • 32
charlax
  • 25,125
  • 19
  • 60
  • 71
  • 4
    See http://stackoverflow.com/questions/1687799/profiling-vim-startup-time – chelmertz Aug 31 '12 at 10:35
  • 2
    Actually, startup is fine. Vim becomes slow after a few minutes of use. It especially concerns `.py` files. – charlax Aug 31 '12 at 10:46
  • 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 Aug 31 '12 at 12:40
  • 2
    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 Sep 03 '12 at 08:47
  • 1
    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. Oct 04 '16 at 14:06

6 Answers6

581

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.

ZyX
  • 52,536
  • 7
  • 114
  • 135
  • 15
    This is amazing. I was able to see that EasyTags is the culprit. Thanks a lot! – charlax Sep 12 '12 at 09:08
  • 1
    This really helped me. I found that vim-signify and tagbar were slowing down vim a LOT. Not worth it! – Mike Funk Feb 01 '14 at 20:52
  • 7
    this helped me to detect "vim-gitgutter" as the clog. – Sebastián Grignoli Mar 10 '14 at 21:52
  • Found the slowness is due to syntax file is sourced multiple times. Have specified filetype in vim modeline & also assigning the filetype in .vimrc based on file extension. So, syntax file is sourced 2 times. – Naga Kiran Jun 26 '14 at 14:16
  • Thanks a lot!! I also found out tagbar was causing the problem. Finally usable again :) – justin Aug 03 '14 at 18:21
  • @blushrt I do not remember any patch altering `:profile` support in 7.4.\* series. This is also useless to complain without giving details. – ZyX Jan 30 '15 at 05:32
  • @ZyX E319: Sorry, the command is not available in this version. More useful now ? – Simon Polak Jan 30 '15 at 06:32
  • 2
    @blushrt You have Vim without profiling support compiled in. You need to get Vim with it. – ZyX Jan 31 '15 at 18:26
  • 3
    How can you identify a specific plugin as being the primary cause of poor performance? I can get information such as below, but am still unclear about what is responsible for calling this and what should be done about it. `FUNCTION 51_Highlight_Matching_Pair()` `Called 1 time` `Total time: 0.669410` `Self time: 0.669410` – jneander Aug 29 '15 at 15:14
  • 6
    @subjectego `:set more | verbose function {function_name}` will show you function contents and where it is located. – ZyX Aug 29 '15 at 19:26
  • Very cool but nothing I found nothing super obvious in terms of time or number of calls, but powerline was overrepresented which lead me to installing lightline instead, so overall learned two new things, thanks! – iamnotsam Oct 09 '15 at 15:13
  • 32
    If it's not clear, the resulting `profile.log` is a file in your Vim session's current directory. – Micah Smith May 10 '16 at 23:13
  • Just for reference: it seems that https://github.com/Yggdroot/indentLine was the culprit for me – Patryk Dec 29 '16 at 10:49
  • 14
    Jump to the end of `profile.log` to see the list of functions sorted by total time (`profile.log` seemed useless to me before I found it there is a sorted list at the end). – Andrey Portnoy Mar 31 '18 at 08:47
  • 1
    Another FYI - Airline was culprit for me. – Damien Roche Jul 04 '18 at 08:46
  • Is it possible to create the log without quitting vim? – Llopeth Dec 14 '18 at 16:59
  • Found the culprit to be vim-devicons – Max Coplan Feb 12 '20 at 21:10
  • My `profile.log` has lines like this: `6 5.828956 3.819220 98_cache()`. How can I find where the function `98_cache()` lives? – Raffi Jul 12 '20 at 17:09
  • Thank you Jesus. vim-airline-clock was fetching the new time every -1 seconds whatever that means, besides a billion times per second. I was able to fix it and got my esc key back. – sammy Jul 25 '20 at 03:59
  • For future reference, `vim-syntastic` was the culprit for files with 10K+ lines. Took ~2s for single cursor movement – Anthony Aug 10 '20 at 08:47
  • Does anyone made already a key bidding with function that will call these commands? That will make debug easier. – milushov Sep 30 '20 at 17:37
  • 1
    @milushov Not a great case for key-binding, IMO. You could put the lines in a file and do `:so filename` on those occasions when you need it. If you really use it a lot then `:nnoremap XXX :so filename` (with XXX whatever you want). ;) – B Layer Oct 12 '20 at 07:33
  • 3
    Here's a oneliner for the first three lines: `:profile start profile.log | profile func * | profile file *` – Cnly May 19 '21 at 10:14
94

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.

feihu
  • 1,935
  • 16
  • 24
  • 3
    Just in case anyone else is wondering, this doesn't exist in all vim/gvim distros. Doesn't in a stock Win Gvim 7.4 over here (though it is documented in viminfo) – thynctank Aug 26 '14 at 16:28
  • 1
    @thynctank I tried on my gvim 7.4 and it worked. Here is my version `IM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 10 2013 14:33:40)` – feihu Aug 27 '14 at 01:17
  • Best answer! Helped me to identify the slowest plugin that made me angry at every vim start. Thanx :) – kovpack Jul 27 '16 at 19:11
  • This and basic `-V` showed it was a non-local `$HOME` causing the issue – bsb Dec 11 '17 at 10:47
  • You need to execute `:e` to refresh the file. Sort the file in place according to the total time taken for each op like so `:%! sort -k2 -nr` – Ashutosh Jindal Aug 02 '18 at 21:41
  • This helped me to find out X11 forwarding the culprit for slow start up. After disabling in my terminal, it just worked fine. – Validus Oculus Jun 16 '21 at 03:45
31

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

Ingo Karkat
  • 167,457
  • 16
  • 250
  • 324
18

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.

Prince Goulash
  • 15,295
  • 2
  • 46
  • 47
13

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

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.

Raffi
  • 970
  • 11
  • 13