Unable to see any startuptime difference

[siduck]

hi @lewis6991! great plugin. I tested with / without impatient and it seems that there's no difference in the startuptime.

https://user-images.githubusercontent.com/59060246/173373975-d5bd27eb-5656-4a98-b739-4c0adc10556e.mp4

My init.lua

Am I missing anything? :c

[lewis6991]

Are you sure your lua plugins are being profiled by --startuptime. From the video, it looks like only vimscript plugins were being measured.

[lewis6991]

Also, don't pass in the default config. There is absolutely no reason ever to do that.

[siduck]

Are you sure your lua plugins are being profiled by --startuptime. From the video, it looks like only vimscript plugins were being measured.

I lazy load 95% of the plugins :v

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.008  000.008: --- NVIM STARTING ---
000.198  000.189: locale set
000.438  000.241: inits 1
000.446  000.008: window checked
000.448  000.002: parsing arguments
002.497  002.049: expanding arguments
002.512  000.015: inits 2
002.819  000.307: init highlight
002.820  000.001: waiting for UI
003.443  000.622: done waiting for UI
003.456  000.013: init screen for UI
003.471  000.015: init default mappings
003.511  000.041: init default autocommands
003.772  000.036  000.036: sourcing /usr/share/nvim/runtime/ftplugin.vim
003.815  000.021  000.021: sourcing /usr/share/nvim/runtime/indent.vim
007.450  003.605  003.605: sourcing /home/sid/.config/nvim/init.lua
007.456  000.283: sourcing vimrc file(s)
007.565  000.080  000.080: sourcing /usr/share/nvim/runtime/filetype.lua
007.589  000.011  000.011: sourcing /usr/share/nvim/runtime/filetype.vim
007.698  000.058  000.058: sourcing /usr/share/nvim/runtime/syntax/synload.vim
007.785  000.179  000.121: sourcing /usr/share/nvim/runtime/syntax/syntax.vim
008.528  000.398  000.398: sourcing /usr/share/nvim/runtime/plugin/fzf.vim
008.552  000.010  000.010: sourcing /usr/share/nvim/runtime/plugin/gzip.vim
008.570  000.007  000.007: sourcing /usr/share/nvim/runtime/plugin/health.vim
008.604  000.025  000.025: sourcing /usr/share/nvim/runtime/plugin/man.vim
008.622  000.008  000.008: sourcing /usr/share/nvim/runtime/plugin/matchit.vim
008.725  000.095  000.095: sourcing /usr/share/nvim/runtime/plugin/matchparen.vim
008.748  000.012  000.012: sourcing /usr/share/nvim/runtime/plugin/netrwPlugin.vim
008.841  000.006  000.006: sourcing /home/sid/.local/share/nvim/rplugin.vim
008.846  000.088  000.082: sourcing /usr/share/nvim/runtime/plugin/rplugin.vim
008.904  000.049  000.049: sourcing /usr/share/nvim/runtime/plugin/shada.vim
008.923  000.008  000.008: sourcing /usr/share/nvim/runtime/plugin/spellfile.vim
008.943  000.011  000.011: sourcing /usr/share/nvim/runtime/plugin/tarPlugin.vim
008.961  000.007  000.007: sourcing /usr/share/nvim/runtime/plugin/tohtml.vim
008.983  000.013  000.013: sourcing /usr/share/nvim/runtime/plugin/tutor.vim
009.004  000.011  000.011: sourcing /usr/share/nvim/runtime/plugin/zipPlugin.vim
009.575  000.024  000.024: sourcing /home/sid/.local/share/nvim/site/pack/packer/start/plenary.nvim/plugin/plenary.vim
014.613  000.011  000.011: sourcing /home/sid/.local/share/nvim/site/pack/packer/opt/neorg/ftdetect/norg.vim
014.619  005.564  005.530: sourcing /home/sid/.config/nvim/plugin/packer_compiled.lua
014.742  000.709: loading rtp plugins
014.848  000.022  000.022: sourcing /home/sid/.local/share/nvim/site/pack/packer/start/plenary.nvim/plugin/plenary.vim
014.925  000.162: loading packages
014.938  000.013: loading after plugins
014.947  000.009: inits 3
016.885  001.938: reading ShaDa
017.086  000.201: opening buffers
017.108  000.021: BufEnter autocommands
017.110  000.002: editing files in windows
017.713  000.602: VimEnter autocommands
017.718  000.005: UIEnter autocommands
017.971  000.189  000.189: sourcing /usr/share/nvim/runtime/autoload/provider/clipboard.vim
017.977  000.070: before starting main loop
027.583  009.606: first screen update
027.588  000.005: --- NVIM STARTED ---

[siduck]

Also, don't pass in the default config. There is absolutely no reason ever to do that.

Any examples of a sample config?

[lewis6991]

Lazy load plugins doesn't work. Don't do it!

You're just removing the startup data from --startuptime. All your plugins are being loaded after --- NVIM STARTED ---.

[siduck]

Lazy load plugins doesn't work. Don't do it!

You're just removing the startup data from --startuptime. All your plugins are being loaded after --- NVIM STARTED ---.

oh I thought I could get some extra speedup in the startuptime with impatient, dumb me! Also I lazy load plugins at certain events & cmds etc ( not deferring or loading them at vimenter ) Sorry for wasting your time

[lewis6991]

There is no way you can lazy load many plugins, Gitsigns especially! Deferring it to something like BufEnter, WinEnter gets you nothing.

The only reason I created this plugin was to reduce the REAL startup time of Gitsigns.

oh I thought I could get some extra speedup in the startuptime with impatient, dumb me! Also I lazy load plugins at certain events & cmds etc ( not deferring or loading them at vimenter ) Sorry for wasting your time

Yes

[siduck]

There is no way you can lazy load many plugins, Gitsigns especially! Deferring it to something like BufEnter, WinEnter gets you nothing.

The only reason I created this plugin was to reduce the REAL startup time of Gitsigns.

oh I thought I could get some extra speedup in the startuptime with impatient, dumb me! Also I lazy load plugins at certain events & cmds etc ( not deferring or loading them at vimenter ) Sorry for wasting your time

Yes

agreed, I was using this for gitsigns and it did give some noticeable change https://github.com/max397574/omega-nvim#gitsignsnvim

[lewis6991]

Except that is going to slowdown startuptime of opening files with actual code.

Let plugin authors determine how a plugin should be loaded and don't try to be smarter than them. If you really have a way to make a plugin more efficient, then raise a PR on said plugin.

[siduck]

Except that is going to slowdown startuptime of opening files with actual code.

Let plugin authors determine how a plugin should be loaded and don't try to be smarter than them. If you really have a way to make a plugin more efficient, then raise a PR on said plugin.

I tried opening a file with actual code and not lazyloading took more startuptime than lazyloading it

https://user-images.githubusercontent.com/59060246/173382590-65b1ed7e-9f0b-43c7-b3ba-8caa1ace7432.mp4

Also not trying to be smarter than plugin authors! total noob with how plugins work

[lewis6991]

Sorry, when I said actual code, I meant something that was under source control. Personally, I don't have any code files I work with which aren't tracked. The lazy-loading will add some additional overhead for these situations. It may be small, but it is there.

If you run a similar benchmark with impatient with a file that loads gitsigns, you should see a significant difference. On my machine it goes from 26ms -> 4ms for loading that single plugin.

[lervag]

Random bypasser here, but just wanted to say that @lewis6991 is very right in recommending to avoid lazy loading of plugins. Expert users that know what they are doing can probably save a few microseconds with lazy loading. However, a lot of plugin authors know what they are doing and rely on "lazy features" already (e.g. autoload for vimscript and require("...") for lua). Also, notice that if you do lazy loading wrong, then you may break things in unexpected ways.

So: Don't do lazy loading unless you know what you are doing! With packer, this means you should not use opt = true for most plugins.

[nullchilly]

@lervag Personally I want an instant overview of the file, for example cpp treesitter loads at (150ms) and vimtex tend to load (76ms) on a relatively small file. vimtex also isn't lua so impatient can't optimize it.

The only way I found that can optimize it is using coq.nvim which adds a layer of sqlite cache. So I even went as far as creating an autocmd to a defer_fn instead of just using ft = 'tex' in packer vim.api.nvim_create_autocmd("FileType", { pattern = { "tex", "plaintex" }, callback = function() lazy "vimtex" end,})

And this is coming from a beefy computer, on my old computer it can easily pass 200ms

So the reason why I lazy load gitsigns or UI plugin in general is to have a quick overview. Deceiving my eyes but not really since I am close the file immediately after 100ms if I want to

[siduck]

Sorry, when I said actual code, I meant something that was under source control. Personally, I don't have any code files I work with which aren't tracked. The lazy-loading will add some additional overhead for these situations. It may be small, but it is there.

If you run a similar benchmark with impatient with a file that loads gitsigns, you should see a significant difference. On my machine it goes from 26ms -> 4ms for loading that single plugin.

tried it with a file containg git diffs, lazyloading still helped. Try that snippet yourself

[lervag]

@lervag Personally I want an instant overview of the file, for example cpp treesitter loads at (150ms) and vimtex tend to load (76ms) on a relatively small file. vimtex also isn't lua so impatient can't optimize it.

The only way I found that can optimize it is using coq.nvim which adds a layer of sqlite cache. So I even went as far as creating an autocmd to a defer_fn instead of just using ft = 'tex' in packer vim.api.nvim_create_autocmd("FileType", { pattern = { "tex", "plaintex" }, callback = function() lazy "vimtex" end,})

Sounds like you match my exception to the rule: "unless you know what you are doing". :)

[lewis6991]

tried it with a file containg git diffs, lazyloading still helped. Try that snippet yourself

If each workload is loading gitsigns, but one workload is running additional lazy loading, the latter will be slower as it is simply running more code. If you're seeing something different, then there must be a flaw in your method of measurement.

This is the issue with many people who attempt to hyper-optimise their startup time. They end up optimizing towards a metric that isn't representative, properly meaningful or even noticeable.

The goal of impatient is to simply optimize the real loading time of Lua modules, whether they are done at startup or sometime after VimEnter. It provides real optimizations by significantly reducing the amount of syscalls and IO operations since all the bytecode to every Lua module is stored in a single file. If your method of measurement doesn't measure the loading of any Lua files, then yes, it won't make a single bit of difference.