ChatGPT解决这个技术问题 Extra ChatGPT

How to see which plugins are making Vim slow?

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

Actually, startup is fine. Vim becomes slow after a few minutes of use. It especially concerns .py files.
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.
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.
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

Z
ZyX

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.


This is amazing. I was able to see that EasyTags is the culprit. Thanks a lot!
this helped me to detect "vim-gitgutter" as the clog.
@subjectego :set more | verbose function {function_name} will show you function contents and where it is located.
If it's not clear, the resulting profile.log is a file in your Vim session's current directory.
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).
f
feihu

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.


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 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)
Best answer! Helped me to identify the slowest plugin that made me angry at every vim start. Thanx :)
This and basic -V showed it was a non-local $HOME causing the issue
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
I
Ingo Karkat

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


P
Prince Goulash

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.


but there are no timing on the log
佚名

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:

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


If it does seem like the syntax highlight file is the culprit, what's the next course of action?
R
Raffi

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.