Scrolling lag, relativenumber, cursorline and large tagfiles

[achilleas-k]

Very likely related to #64 and very similar behaviour to LaTeX-Box-Team/LaTeX-Box#163

After turning on highlighting (which I usually keep off - turned it on recently because I noticed the discussion on improving performance), I noticed that scrolling (hjkl) was extremely slow when editing my ~/.vimrc file. The input latency becomes so large that holding one of j or k for a couple of seconds and releasing keeps the cursor moving for a few seconds longer.

Checking my tag files, the tags for vim were around 1M, which I know is a good way to cause issues with highlighting and easytags. However, before deleting, I did a bit of profiling and noticed that 56_Highlight_Matching_Pair() was causing the scrolling issue, which is what reminded me of LaTeX-Box.
So I tried toggling the same options I mention in the LaTeX-Box issue.

:NoMatchParen
:set norelativenumber
:set nocursorline

Disabling these three options while keeping highlighting on and having a big tags file makes the issue disappear completely. The cursor scrolls with a smoothness and responsiveness I only see when vim runs with no plugins or user options. A bit more testing revealed that :NoMatchParen is unnecessary and just dropping the cursorline and relativenumbers is enough.

I ended up deleting my vim tags file and keeping the options on and all is well. The reason I'm opening an issue is because I don't understand why a big tag file coupled with those options causes this much latency. More importantly, is there any other way around the issue? I have other tag files, for other languages, where I would want to be able to keep the tags and also keep the options on.

[xolox]

Hi and thanks for the feedback. A couple of points:

• The performance improvements won't make a difference for syntax highlighting in Vim scripts unless you've added let g:easytags_syntax_keyword = 'always' to your vimrc.
• You say 56_Highlight_Matching_Pair() jumped out during profiling and was causing the lag, but then you go on to say that :NoMatchParen is unnecessary. So which is it? :-)

Is your conclusion that the interaction between 1) Vim's syntax highlighting engine, 2) the match paren functionality, 3) the relativenumber option and 4) the cursorline option is to blame for all of this? That's interesting but it doesn't really help me because those options are built into the core of Vim and disabling them won't be an option (no pun intended) for a lot of users of the vim-easytags plug-in :-(

I must say I've noticed similar things; I never use relative line numbers but I sometimes enable cursorline and the resulting lag during scrolling is unbelievable. But for me this happens even in buffers where vim-easytags is not active.

All in all I'd desperately like to fix the performance issues with vim-easytags but currently I don't really see how, at least not the performance issues that occur once vim-easytags has defined its custom highlighting patterns and Vim goes all wonky :-(

[achilleas-k]

The performance improvements won't make a difference for syntax highlighting in Vim scripts unless you've added let g:easytags_syntax_keyword = 'always' to your vimrc.

I see. I guess I wasn't paying too much attention to the discussion on the performance improvements. It doesn't seem to help or relate to the scrolling issue, then.

You say 56_Highlight_Matching_Pair() jumped out during profiling and was causing the lag, but then you go on to say that :NoMatchParen is unnecessary. So which is it? :-)

You're right, my first post on the issue is a bit of a mess because I'm not sure how it all relates. 56_Highlight_Matching_Pair() did jump out during profiling and it was what reminded me of the other issue. The fact that this issue goes away without :NoMatchParen would suggest they're unconnected. The reason I mentioned it, while risking confusion, was firstly because that's how I came to discover how to work around the issue and secondly because there might be something else going on related to 56_Highlight_Matching_Pair() that's bogs down cursor movement when a redraw of the line numbers and cursorline is needed.

Is your conclusion that the interaction between 1) Vim's syntax highlighting engine, 2) the match paren functionality, 3) the relativenumber option and 4) the cursorline option is to blame for all of this?

I would need to test more and with other filetypes/languages, so I'll put down a preliminary "maybe".

That's interesting but it doesn't really help me because those options are built into the core of Vim and disabling them won't be an option (no pun intended) for a lot of users of the vim-easytags plug-in :-(
I must say I've noticed similar things; I never use relative line numbers but I sometimes enable cursorline and the resulting lag during scrolling is unbelievable. But for me this happens even in buffers where vim-easytags is not active.

I understand it's not very helpful since there's not much one can do with built-in features other than disable them. I suppose I was looking for insight on how tag highlighting interacts with the other options and whether any connection makes sense.

[achilleas-k]

This issue should probably be closed. The scrolling lag can't be avoided when the two options, relativenumber and cursorline, are enabled. I believe the reason for this is that options like these cause a redraw of several parts of the window.
The documentation for cursorline, for instance, mentions that it will "make screen redrawing slower". It's also possible to see a block cursor flash in certain parts of the screen. For instance, with relativenumber enabled, I can see a cursor flash next to the line number of the last line while moving the cursor vertically, even when not scrolling the screen (i.e., moving the cursor up/down in the middle of the screen).

It would seem that when HighlightTags is enabled, these redraws likely trigger a rescanning of the tags on screen, which means that with every vertical cursor movement, the function is called (I'm just speculating here, please confirm). If this is the case, unless there's a way to detect these cases specifically and avoid redrawing/rehighlighting tags (which is unnecessary when the screen hasn't scrolled), then there's no way to fix the issue.

[yantis]

After writing and loading a file I had really bad scroll lag as well and tried all the fixes above but in the end the lag was unbearable. Though I get no lag until I save and reload file.

With a 3k tags file it was fine but at 30k the lag got pretty bad. In the end the fix for me was simply setting vim to use the old regex engine:
set regexpengine=1

100% reproducible. If I set regexpengine=0 it lags again.

This is on vim 7.4.560 on Archlinux

[copyme]

@yantis You make my day. This really solve the problem. openSUSE 13.1 vim 7.4 with patches 1 - 52.

[jan-warchol]

I was having similar issues with lag, and changing regex engine really helped. Thanks @yantis !