Re: Improving vim startuptime

On 2023-07-16, Manas <manas18244@iiitd.ac.in> wrote:
> `startuptime` surprisingly shows me a mere 656ms, while hyperfine shows
> me 2.7s. I am not sure how this discrepancy is arising. Here is the full
> log. https://pastebin.mozilla.org/uTrJ7i8N
>
> I see 234ms (out of those 656ms, ~35%) due to VimEnter autocommands.

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?

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.

--
--
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/u91m31%24sdn%241%40ciao.gmane.io.