Performance problem with `n` in ft=dircolors

[blueyed]

With some syntax files the remapped n method appears to be noticeably slower than the default.

TEST CASE:

1. wget https://raw.githubusercontent.com/trapd00r/LS_COLORS/master/LS_COLORS -O .dircolors
2. vim .dircolors (filetype should be dircolors)
3. /38<cr>
4. Press n multiple (10) times

Profiling Vim reveals this:

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
   11   3.928132   0.004230  <SNR>50_next()
   15   3.279414   0.092468  <SNR>256_reset_colors()
10439   3.194810   3.012284  <SNR>256_preview_color()
   14   3.101751   0.044484  <SNR>31_SynSet()
   13   1.488085   1.480977  <SNR>295_OnBufferVisit()
   27   0.946004   0.000607  airline#extensions#branch#get_head()
   27   0.945397   0.002644  airline#extensions#branch#head()
   27   0.942158   0.005701  VCSCommandEnableBufferSetup()
   27   0.936457   0.000294  <SNR>121_SetupBuffer()
   …

FUNCTIONS SORTED ON SELF TIME
count  total (s)   self (s)  function
10439   3.194810   3.012284  <SNR>256_preview_color()
   13   1.488085   1.480977  <SNR>295_OnBufferVisit()
    1              0.123230  <SNR>295_SetUpPython()
   14   0.103036   0.101804  <SNR>26_LoadFTPlugin()
 7139              0.094674  <SNR>256_get_256color()
   15   3.279414   0.092468  <SNR>256_reset_colors()
   14              0.092290  <SNR>235_findinrtp()
 7139              0.087852  <SNR>256_get_hi_str()
   14   3.101751   0.044484  <SNR>31_SynSet()
    2   0.036410   0.034918  _oblique_on_change()
   …

vim-oblique appears to trigger expensive parts in the dircolors syntax handling.

[junegunn]

Nice find! I didn't realize that silent! doautocmd ... could be so slow.

[blueyed]

Thanks! That fixed it.

It seems like this might be a problem in Vim and should get optimized there, too?

Grepping my Vim plugins it appears to be a common practice.

[junegunn]

Yeah, it's strange. I don't understand why doautocmd in this very context is so slow. The above commit circumvents the problem by not doing it when it's not needed, but if you indeed have some action to perform on ObliqueRepeat (e.g. autocmd User ObliqueRepeat normal! zz) you'll still notice the enormous slowdown.

[blueyed]

Looking at Vim's source the problem is likely the modelines that get applied over and over again.

https://github.com/vim-jp/vim/blob/local/src/ex_docmd.c#L5093-5102

(# vim: ft=dircolors:fdm=marker:et:sw=2:)

This can be disabled using <nomodeline> (:do[autocmd] [<nomodeline>] [group] {event} [fname]).

As for Vim I think an optimization would be to skip this if there are no events defined / executed.

[blueyed]

I've proposed this performance improvement on the mailing list:https://groups.google.com/forum/#!topic/vim_dev/DidKMDAsppw

[junegunn]

Solid investigation, thanks :+1: I'll also consider using <nomodeline> if it's available.