-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plugin is always autoloaded #25
Comments
Thanks for the kind words! 😄 I agree, loading could be improved quite a bit. I am curious, have you noticed an unacceptable load time, or is this a "best practices" concern? I'm planning to re-organizing pretty things soon, I'm just looking to gauge priority. |
It's mostly just best-practice, but the current setup does add 5-10 ms to startup. |
Measuring vim startup time for my vimrc, the plugin matchup is actually the one which adds the most to the startup (and I have installed 81 plugins (right now with some redundancy ctrlp, fzf, denite)
I think for people like me who use many plugins, it would become a problem if all plugins would add a similar time to startup. Therefore I would argue it is too much. |
I've made substantial changes to the loading which should have brought the time down. Feel free to report if the startup cost is still excessive. |
Thanks Andy! Yes, this is a significant improvement. And I would have never called matchup excessive. Anyhow. Now it looks like:
Unfortunately, it still is one that adds more than others but is not ahead as the last time. It had been 13ms difference to the next plugin, now the difference is only 3ms. I would call this acceptable. I have one more question: If I would not use certain features of matchup, could I improve the startup time further, e.g. using only text objects and motions but no highlighting? I have tried
but this did not change much. Could this be improved? |
Also be more robust in loading pi_paren's plugin/matchparen.vim cf. #25, cf. SpaceVim/SpaceVim/#1482
I think that should be fixed now. |
My first check does not confirm that |
I did some additional profiling, using a clean
❯ cat vimrc
set nocompatible
syntax on
" let g:matchup_matchparen_enabled = 0 " if measured
" colorscheme apprentice " if measured
" colorscheme base16-gruvbox-dark-hard " if measured Measurement (100 runs)
I have compared
I would have hoped that The colorscheme adds a bit more than matchup, and fugitive is the second "slowest" plugin I use right now. Most of my other plugins are in the same region as Another thing I learned is: colorschemes can be quite slow: I intend now to measure the startup impact as a first step when considering to use a new colorscheme. There are some really slow ones (e.g. https://github.com/rakr/vim-one which increases startup to 122ms without any additional plugin; this has been reported in issue 74; I would call this excessive 😃). Anyhow, I am no expert in writing vim plugins and can't really make a recommendation how one could minimize startup time further. My expectation was that matchparen functionality would have a larger impact but apparently this is not the case. |
Thanks so much for the detailed timings! Could you show me an example of a vim-startup-{}.log file? Specifically with and without matchup_matchparen? I also wonder if your installation method has anything to do with it. I've never used or tested |
I can certainly show you an example of a vim-startup{}.log file Default matchup
Matchup without matchparen
|
If I got justinmk right, there should be no As a further step I will try to use the lazy loading functionality of vim-plug or dein. If they are helpful to improve startup time of matchup, one can at least point people to a currently available possibility to improve startup time (IF someone complains). |
Well, I could (and may) place them in The other thing you could try is |
Using
Comparing again to
It looks like |
I improved the load time even further for plain text files, so the startup time should differ less between the states of the |
The call to
matchup#init()
inplugin/matchup.vim
defeats the purpose ofautoload/
, it causes vim to source theautoload/
scripts as soon asplugin/matchup.vim
is sourced (for most users that means "during startup"). Normally, plugins should keep minimal stuff inplugin/matchup.vim
and only trigger autoload on first use.It's somewhat academic since most files will need matchup, but if user starts vim to view text files or logs, or blank, startup cost for matchup is still present.
Really nice work on this plugin, use of the statusline is cool.
The text was updated successfully, but these errors were encountered: