Interaction effect with vim-bundle adding 1.2 seconds to startup time

[Jack Kinsella]

In a mid-sized Rails project, when I ran nvim . --startuptime /tmp/vim.log, I got the following standout entry

1725.080  1245.209: BufEnter autocommands

Running :au BufEnter in vim revealed the following callers

--- Autocommands ---
filetypedetect  BufEnter
    *.xpm     if getline(1) =~ "XPM2" |   setf xpm2 | else |   setf xpm | endif
    *.xpm2    setf xpm2
gitgutter  BufEnter
    *         call s:on_bufenter()
indent_guides  BufEnter
    *         call indent_guides#process_autocmds()
NERDTree  BufEnter
    NERD_tree_*
              stopinsert
NERDTreeHijackNetrw  BufEnter
    *         call nerdtree#checkForBrowse(expand('<amatch>'))
ALEEvents  BufEnter
    *         call ale#events#ReadOrEnterEvent(str2nr(expand('<abuf>')))
peekaboo_init  BufEnter
    *         if !exists('*getcmdwintype') || empty(getcmdwintype()) | call peekaboo#on() | endif
asyncomplete_enable  BufEnter
    *         if exists('b:asyncomplete_enable') == 0 | call asyncomplete#enable_for_buffer() | endif
railsPluginAuto  BufEnter
    *         if s:active() |   if get(b:, 'rails_refresh') |     let b:rails_refresh = 0 |     let &filetype = &filetype |     unlet! b:rails_refresh |   endif |   if exists("+completefunc") && &completefunc ==# 'syntaxcomplete#Complete' |     if exists("g:loaded_syntax_completion") |       unlet g:loaded_syntax_completion |       silent! delfunction syntaxcomplete#Complete |     endif |   endif | endif

I noticed that if I removed vim-rails the startup time became fast again, with the BufEnter bit going down over 10x to 102.469.

When I remove all plugins except vim-rails, everything is also super fast. So the issue is an interaction effect between this plugin and some other(s).

I'm happy to investigate myself but I thought I'd post in case you've any pointers on what would be worthwhile for me to look at.

[Jack Kinsella]

Update: Found the interaction plugin: tpope/vim-bundler. When I comment that out, everything is lightning fast again.

[Tim Pope]

Parsing a large Gemfile.lock can indeed take some time, and rails.vim forces it to be eager. We already cache the hell out of it, so it only happens on loading the first file, or when the lock file changes.

Long term, this can be sped up by using Vim 9's faster function definitions, but if you're on nvim it'll probably be a while before you can reap the benefits of that. I don't have another suggestion other than to disable bundler.vim, although that will reduce functionality.

That BufEnter event does very little and is probably a red herring. The FileType event is where the real work is happening.