如何查看哪些插件使Vim变慢？

本文翻译自：How to see which plugins are making Vim slow?

Is there a way to profile Vim plugins? 有没有办法分析Vim插件？

My MacVim becomes slower and slower when I open a large .py . 当我打开一个大的.py时，我的MacVim变得越来越慢。 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 我的dotvim在这里： https ： //github.com/charlax/dotvim

---

#1楼

参考：https://stackoom.com/question/Pfjv/如何查看哪些插件使Vim变慢

---

#2楼

I have found it helpful to print all Vim activity to a file by starting Vim with the -V option: 我发现通过使用-V选项启动Vim可以将所有Vim活动打印到文件中：

vim -V12log

This provides the maximum verbosity (level 12) and outputs it to the file log . 这提供了最大的详细程度（级别12）并将其输出到文件log 。 You can then perform some Vim actions which you know to be slow, and then see which functions/mappings are being called internally. 然后，您可以执行一些您知道速度很慢的Vim操作，然后查看内部调用的函数/映射。

---

#3楼

It could be a plugin or the syntax highlighting; 它可以是插件或语法突出显示; try a :syntax off when this happens and see whether Vim instantly gets faster. 尝试a :syntax off当发生这种情况时，看看Vim是否会立即变得更快。

With plugins, a "general slowness" usually comes from autocommands; 对于插件，“一般的缓慢”通常来自自动命令; a :autocmd lists them all. a :autocmd列出所有。 Investigate by killing some of them via :autocmd! [group] {event} 调查通过以下方式杀死其中一些:autocmd! [group] {event} :autocmd! [group] {event} . :autocmd! [group] {event} 。 Proceed from more frequent events (ie CursorMoved[I] ) to less frequent ones (eg BufWinEnter ). 从更频繁的事件（即CursorMoved[I] ）到较不频繁的事件（例如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. 如果你可以在某种程度上可靠地重现这种缓慢，那么二进制搜索可能有所帮助：将~/.vim/plugin/一半文件移走，然后移动另一个，在缓慢的集合中重复。

If you really need to look under the hood, get a Vim version that has the :profile command enabled. 如果你真的需要深入了解，请获取一个启用了:profile命令的Vim版本。 (Not the vanilla BIG Windows version, but the one that ships with Cygwin has it; also, self-compiling is quite easy under most distros.) （不是vanilla BIG Windows版本，但Cygwin附带的版本有它;而且，在大多数发行版中，自编译非常容易。）

---

#4楼

You can use built-in profiling support: after launching vim do 您可以使用内置的分析支持：启动vim后

: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). （不像退出noautocmd不是真的需要，它只是让vim退出更快）。

Note: you won't get information about functions there were deleted before vim quit. 注意：在vim退出之前，您将无法获得有关已删除的功能的信息。

---

#5楼

I found another very helpful vim buildin method to show the exactly timing messages while loading your .vimrc. 我发现了另一个非常有用的vim buildin方法，用于在加载.vimrc时显示准确的计时消息。

vim --startuptime timeCost.txt timeCost.txt

Please run: 请运行：

:help --startuptime

in VIM to get more information. 在VIM中获取更多信息。

---

#6楼

If you're having problems with screen update operations ( ^L , scrolling, etc) being slow, your problem may be an inefficient syntax highlighting file. 如果您在屏幕更新操作（ ^L ，滚动等）方面遇到问题，那么您的问题可能是一个低效的语法高亮文件。 You can test this by temporarily disabling syntax highlighting ( :syn off ) and seeing if the problem goes away; 您可以通过暂时禁用语法突出显示（ :syn off ）并查看问题是否消失来对此进行测试; if you want to dig into the details, you can profile the current syntax file using :syntime : 如果您想深入了解详细信息，可以使用:syntime配置当前语法文件:syntime ：

1. Open a file that causes syntax highlighting performance issues. 打开导致语法突出显示性能问题的文件。
2. Run :syntime on to start profiling. 运行:syntime on以开始分析。
3. Scroll through the file a bit. 滚动文件一下。
4. Run :syntime report to generate a report. 运行:syntime report生成报告。 The patterns listed first in the report are the ones which took the most time to process. 报告中首先列出的模式是花费最多时间处理的模式。