Re: Improving vim startuptime

On Sun, Jul 16, 2023 at 09:05:37PM -0000, Lifepillar wrote:
> 170ms are also spent loading buffers. Do you need those to be loaded
> eagerly at startup? Also, is context.vim for ConTeXt? ConTeXt support is
> built-in into Vim (`:help ft-context`): do you need a plugin for that?
> If so, why loading it at startup?
No it is different. [context.vim](https://github.com/wellle/context.vim)

I have found it quite useful for large codebases.

>
> In general, if you see `autoload` paths in the output of --startuptime,
> you should look further, because those are likely files that do not need
> to be loaded at once.
>
> You may shave some time off by avoiding loading built-in plugins that
> you know you'll never use. In my vimrc, I disable some of those as
> follows:
>
> let g:loaded_getscriptPlugin = 1
> let g:loaded_gzip = 1
> let g:loaded_logiPat = 1
> let g:loaded_rrhelper = 1
> let g:loaded_tarPlugin = 1
> let g:loaded_vimballPlugin = 1
> let g:loaded_zipPlugin = 1
>
> But your startup time is relatively high (mine is <60ms, an order of
> magnitude less than yours, but still three times more than `vim
> --clean`!), so I'd first act on the slowest parts. Certainly, you should
> (and likely could) try to bring the number of autocommands close to
> zero.
>
> > My autocommands are just scattered throughout vimrc. Most of them are
> > like:
> >
> > au FileType <list> [mappings|calls]
> >
> > Maybe there is a way to organize them better?
>
> Put filetype-specific stuff under
>
> ~/.vim/after/
>
> For instance, these are a few things you may put in
> ~/.vim/after/ftplugin/tex.vim for (La)TeX files:
>
> " Local settings
> setlocal conceallevel=0
>
> " Filetype-specific mappings
> nnoremap <silent><buffer> <leader>tp :<c-u>update<cr>:PdfLaTeX<cr>
>
> " Filetype-specific commands
> command! -buffer -nargs=? -complete=file PdfLaTeX call local#tex#typeset(<q-args>)
>
> Anything that does not need to be immediately available when the
> filetype is set goes into a corresponding autoload file. In the example
> above, the typeset() function is needed only when the user executes
> :PdfLateX. That function is then defined in a separate
> ~/.vim/autoload/local/tex.vim (I put my own stuff under a `local`
> directory, but that's just my convention: any tree structure under
> `autoload` will do).
>
> Btw, this example is in legacy Vim script, but if you are starting
> afresh I'd recommend using the new Vim 9 script syntax. See `:help
> vim9`.
>
> The same concept applies to your vimrc: anything that does not need to
> be set at once when Vim starts should be turned into an autoload
> function.
>
> > And there are a ton of plugins too. Is there any way to only source them
> > conditionally?
>
> Yes. Put them under ~/.vim/pack/SOMEDIR/opt, where SOMEDIR is a name of
> your choice. Then, use `packadd` to load them when necessary, either
> manually or automatically. For instance, this is my Tagbar configuration
> in my vimrc:
>
> let g:tagbar_ctags_bin = '/opt/local/bin/uctags'
> nnoremap <silent> <leader>vt :<c-u>silent call local#tagbar#toggle()<cr>
>
> Then, the function that lazily loads the plugin and toggles the tag bar
> is in ~/.vim/autoload/local/tagbar.vim:
>
> fun! local#tagbar#toggle()
> if !exists("g:loaded_tagbar")
> packadd tagbar
> endif
> TagbarToggle
> endf
>
> You are using a plugin manager: I would also check whether the plugin
> manager has a way to defer loading plugins.
>
> > I can also try removing some of the old plugins. I haven't done a
> > cleanup in a while.
>
> That's a very good idea: as you become more comfortable with Vim, you
> should review your plugins and get rid those that you are able to
> replace with your own code (if you are willing to spend time on writing
> your own stuff, of course) or with Vim built-in functionality.
>
> For each plugin, ask you yourself:
>
> - do I really need this? Maybe Vim already provides >90% of what the
> plugin does, and I just need to learn Vim a bit better. I may live
> without the remaining <10%, write my own code to fill the gap, or find
> another plugin that covers just that 10%. Sites like
> https://vim.fandom.com/wiki/Vim_Tips_Wiki may be helpful.
> - Am I fully making use of this plugin? Sometimes, a plugin has
> a hundred features, but I am using two or three. Maybe, I can
> implement those two or three features myself?
> - Is there an equivalent plugin that's less complex and possibly faster?
> Fortunately, the Vim plugin ecosystem is vast. And the less popular
> alternative is often as good or better than "what people is using".
>
> Hope this helps,
> Life.
>

These are really phenomenal tips. Thanks a lot, Life. I am refactoring
the plugins now. I hope to make things under 100ms.

--
Manas

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6do5ihxten73psjxrcjnulmiu56gn45rjm7f7st6zfnixooh3s%40pqgvnerrjfji.