Tagbar is making Vim's cursor lag

[charlax]

Hi,

After a few minutes of use, my Vim is getting very slow, even when something as simple as moving the cursor.

I profiled the running function and got this result:

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
    3   0.006288   0.002934  <SNR>79_AutoUpdate()
    3   0.003460   0.001882  xolox#easytags#autoload()
    3   0.002858   0.000117  <SNR>79_HighlightTag()
    3   0.002741   0.002732  <SNR>79_GetNearbyTag()
   15   0.001804             <SNR>44_Highlight_Matching_Pair()
    3   0.000657   0.000507  xolox#easytags#get_tagsfile()
   21   0.000559             xolox#misc#option#get()
    3   0.000361   0.000083  xolox#easytags#file_has_tags()
    6   0.000279   0.000088  <SNR>31_resolve()
    3   0.000252   0.000223  <SNR>79_IsValidFile()
   18   0.000191             <SNR>79_LogDebugMessage()
    3   0.000170             xolox#easytags#supported_filetypes()
    3   0.000157             <SNR>31_cache_tagged_files()
    9   0.000051             112()
    3   0.000017             114()
    3   0.000014             <SNR>31_create_context()
    3   0.000014             111()
    3   0.000009             110()

FUNCTIONS SORTED ON SELF TIME
count  total (s)   self (s)  function
    3   0.006288   0.002934  <SNR>79_AutoUpdate()
    3   0.002741   0.002732  <SNR>79_GetNearbyTag()
    3   0.003460   0.001882  xolox#easytags#autoload()
   15              0.001804  <SNR>44_Highlight_Matching_Pair()
   21              0.000559  xolox#misc#option#get()
    3   0.000657   0.000507  xolox#easytags#get_tagsfile()
    3   0.000252   0.000223  <SNR>79_IsValidFile()
   18              0.000191  <SNR>79_LogDebugMessage()
    3              0.000170  xolox#easytags#supported_filetypes()
    3              0.000157  <SNR>31_cache_tagged_files()
    3   0.002858   0.000117  <SNR>79_HighlightTag()
    6   0.000279   0.000088  <SNR>31_resolve()
    3   0.000361   0.000083  xolox#easytags#file_has_tags()
    9              0.000051  112()
    3              0.000017  114()
    3              0.000014  <SNR>31_create_context()

So apparently TagBar and EasyTags are causing most of the lag.

Any Python file will make Vim slow, especially big ones. My vim dotfiles are here: https://github.com/charlax/dotvim

I did not change updatetime.

Thanks for your help!

[majutsushi]

Hm, that doesn't really look like Tagbar or EasyTags are responsible. The timings are all in the millisecond range, and the functions only got called a few times. I don't use EasyTags, but Tagbar doesn't do anything while you're typing, it only updates after a CursorHold event, so that can't really cause a slowdown. If the profiling doesn't help I would suggest disabling some plugins and checking whether it still occurs and then narrowing it down using that method.

[charlax]

Yes, but the only action I did was moving the cursor down three lines...

And disabling both plugins solves the problem.

[majutsushi]

What happens if you only disable one of them? Also, how exactly does this slowness manifest itself? What does :verbose autocmd CursorMoved report?

[charlax]

:verbose autocmd CursorMoved
--- Auto-Commands ---
matchparen  CursorMoved
    *         call s:Highlight_Matching_Pair()
        Last set from /usr/local/Cellar/macvim/7.3-64/MacVim.app/Contents/Resources/vim/runtime/plugin/matchparen.vim 

Vim becomes slow after a few minutes, especially when I have a few files opened in different tabs + split, and with big files. It manifests itself with annoyingly slow cursor movement, and any other action is slow (in particular editing).

I'll try disabling only one of them, thanks for your help!

[charlax]

The :verbose autocmd CursorMoved reports the same thing whether none or one of the plugin is enabled.

[majutsushi]

But what about the slowness? Does it only happen with one of the plugins?

[jason0x43]

I'm experiencing a similar problem, except that I see the slowdown immediately under the right conditions. I haven't yet determined whether the problem is due to file size (I see the slowdown on a 13k-line C file and a 6600 line Python file) or because each of those files contain really big arrays (thousands of lines). In any case, the slowdown becomes more pronounced the further into the file I move the cursor. So when I open one of the target files and move around the first few lines, everything is normal. If I jump to the end of the file, cursor motion becomes very sluggish. If I jump back to the beginning, the cursor moves normally again.

The problem appears to be a conflict between tagbar and powerline. If I disable all my plugins except tagbar, I don't see a slowdown. If I disable everything but powerline, I also don't see a slowdown. If I have both tagbar and powerline enabled (even if those are the only two), I see the slowdown. I see the same behavior whether or not I have the 'currenttag' segment installed. I'm still poking at it to see what exactly is causing the problem.

[charlax]

@majutsushi the slowness does not happen when I disable EasyTags. I disabled EasyTags.

Also, using the latest version of MacVim on Mountain Lion resulted in a noticeable boost.

[jason0x43]

I'm seeing pretty consistent behavior in gvim 7.3 on Windows and Linux, and vim 7.3 in cygwin.

[jason0x43]

After some further testing, I'm thinking it's filesize related. The issue manifests when viewing /usr/include/xcb/xproto.h, which is 446k (15324 lines) on my Ubuntu 10.04 test system. The file is fairly large, but it's made up of fairly small data structures. Vim requires multiple seconds to initialize when opening the file, and movement becomes exceedingly sluggish as the cursor nears the end of the file. The problem is most visible (well, aside from the slow startup) when trying to scroll quickly in any direction by holding down a key.

As before, disabling either powerline or tagbar makes the problem go away.

[majutsushi]

Yes, large files can lead to noticeable delays. There is unfortunately not much I can do about that, some of the problems have to do with the work that Tagbar has to do to properly parse the tags, and others with the speed of Vim's native functions.

The most complicated thing that Tagbar has to do when parsing the ctags output is to figure out the correct scope of the tags. For this it has to call the filter() function a few times with a rather complicated condition, and that is what takes up most of the time. The filter() function is rather slow by itself, and since I have to call it twice with the same condition to split a list in two this has a large impact on Tagbar's performance. The only real way to improve that would be to either make that function faster in Vim itself, or at least to make it possible to split a list in two instead of removing the non-matching elements.

The sluggishness at the end of the xproto.h file has a different reason. I noticed that the bottom over 10.000 lines of that file are nothing else but prototypes, and prototypes aren't shown in the statusline functionality by default. This means that the function that looks for the closest tag has to look at a lot of lines every time the statusline gets updated, which is among others every time the cursor gets moved. I tried replacing the algorithm that looks for the closest tag with a different one, but that just exchanged one slow operation with another one, and the second one was again dependent on the speed of Vim's native functions. I think that your case is very rare, though, especially since that file is auto-generated and probably shouldn't be edited by hand anyway, so it probably isn't much of a problem in the majority of case. But if for some reason you do want to edit that file then allowing prototypes to be shown in the statusline (explained in :h tagbar-extend) should remove the sluggishness.

[armw4]

Easytags turned out to be a huge tax on my system. I disabled it, and now my MacVim instances are lightening fast!!!

[alerque]

It reading through the history here it sounds to me like EasyTags was the culprit. Enough time has passed that it might have been fixed. In any case I don't see a current issue that needs addressing in this plugin. If I'm wrong about that please feel free to comment here and I'm happy to re-open this and look into it.

The other performance related issue that I'll crosslink here in case people find this on search is #494, which has to do with the lag between buffer changes and tagbar updates. Different issue, but seems to be a common point of confusion.

[bam80]

@alerque Did you try with xproto.h? Any dependency on file size?

[alerque]

@bam80 This comment already details pretty much what can and can't be done about the edge case seen in xproto.h, and also explains the large file size. File size itself isn't even the issue, how many symbols they spit out is. But that isn't what this issue was about, this issue was opened for another reason and I don't see anything left related to that to track here.