plugin: --startuptime statistics and visualization

[xelra]

I think it would be really great if something like timecop could be added directly into Neovim. For many users, using Neovim is all about performance. With the --startuptime option already there, I think all that's missing is some kind of cli visualization and statistic. It would be great to have it show on :timecop.

I think just dumping a file and then leaving the user to "visualize it however you want" isn't a great user experience.

[justinmk]

Can you link to the plugin? No objection to including it if someone does the work and it's small and well written.

[xelra]

There's no plugin like that yet. There are some data plotters that create a graph based on the output of --startuptime.

I was imagining something similar to :CheckHealth. With no graphics. A sorted list of startup times per plugin.
Then optionally maybe as the icing on the cake, a bar plot that visually looks like an airline, so it works in the terminal emulator.

[ghost]

Maybe @bchretien 's vim-profiler is one such candidate. It does already the profiling/statistics part:

$ vim-profiler.py nvim

Running nvim to generate startup logs... done.
Loading and processing logs... done.
Plugin directory: /home/user/.config/nvim/plugged
=====================================
Top 10 plugins slowing nvim's startup
=====================================
1         4.559   vim-fugitive
2         4.162   tcomment_vim
3         3.936   vim-hybrid
4         2.922   lightline.vim
5         1.551   supertab
6         1.522   vim-sneak
7         1.100   ultisnips
8         0.929   fzf.vim
9         0.916   fzf
10        0.877   vim-surround
=====================================

[xelra]

@toogley That output is pretty close to what I had in mind. Unfortunately vim-profiler depends on Python. I think something as essential as this, shouldn't have any dependencies.
Also it misses the stats for Neovim itself. It can profile system plugins, but profiling Neovim itself is just as important for putting the numbers in comparison. I mean, reducing plugin startuptime from 10 to 5 ms might seem like a good idea, when not seeing the startuptime of Neovim itself. But when compared to 80 ms startuptime for Neovim itself, it was just an exercise task.

The second problem with vim-profiler is that it depends on which plugin-manager you use. For example it doesn't work with dein.vim. It also doesn't work on Windows.

[tweekmonster]

I took a stab at this: https://github.com/tweekmonster/startuptime.vim

It doesn't care about plugin managers and you can run it in Vim.

[justinmk]

Neat that it does multiple samples. Why not Windows?

[ghost]

@tweekmonster looks great!

[xelra]

@tweekmonster Awesome. That's perfect (if it were to run on Windows also). I bet that plugin will skyrocket in popularity.

[tweekmonster]

Neat that it does multiple samples. Why not Windows?

Didn't want to spend the time on it at 2AM. I also didn't know if there was something like script that could avoid the 2 second delay Vim adds when it doesn't have an interactive session.

[justinmk]

I also didn't know if there was something like script that could avoid the 2 second delay Vim adds when it doesn't have an interactive session.

Well, we can fix the 2-second delay in nvim core. I think we should ship the plugin with nvim. Though for that purpose I would suggest :CheckStartup as the command name.

[justinmk]

BTW newer versions of Vim have the --not-a-term argument to avoid the 2-second delay.

[tweekmonster]

nvim also has --headless which also works, though I didn't confirm if that causes the results to be inaccurate. The other part of the reason is the script uses ps to get the process's path because I wanted it to run what the user is using, not what's just found in $PATH. Is the executable something that can be exposed too?

[tweekmonster]

If this ships with nvim, I demand we keep the Mortal Kombat text.

[chrisbra]

The other part of the reason is the script uses ps to get the process's path because I wanted it to run what the user is using, not what's just found in $PATH.

You can use v:progpath

[jamessan]

You can use v:progpath

@chrisbra That's not absolute in Vim, so it may not run the correct binary. @brammool decide the cost of determining that once at startup was too great, so instead the user has to deal with the uncertainty if they :cd after starting vim.

All that would need to change is to use findYourself to determine the value for v:progpath instead of setting it to the raw argv[0] value. I think the usability of an accurate value for v:progpath here far outweighs the minimal overhead of calling findYourself.

[chrisbra]

@jamessan I didn't remember that (and I think I rely on the exact path in some plugin already). Perhaps we should bring that issue up on vim_dev again?

[tweekmonster]

You can use v:progpath

That's not absolute in Vim, so it may not run the correct binary.

I was just trying this out and it's not even influenced by :cd. From what I can see, it's just argv[0] in Vim.

[justinmk]

@tweekmonster need to to exepath(v:progpath), see :h v:progpath

[tweekmonster]

need to to exepath(v:progpath), see :h v:progpath

This doesn't help if the current process isn't in $PATH.

[brammool]

Tommy Allen wrote:

> need to to exepath(v:progpath), see :h v:progpath This doesn't help if the current process isn't in `$PATH`.

Then it must be an absolute or relative path. This is a common problem in Unix, argv[0] is the only thing the process gets, you have to figure out the actual location yourself somehow.

…

-- Don't believe everything you hear or anything you say. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[tweekmonster]

Then it must be an absolute or relative path.

Yes, but if it is relative, the best place to resolve this would be in the user's vimrc since another plugin could change cwd before my plugin can resolve it. On some systems, I could just resolve it from procfs, but I can't use sysctl() on BSD/Darwin, or GetModuleFileNameW() on Windows.

If performance is an issue, couldn't the path be resolved the first time v:progpath is accessed?

[tweekmonster]

Just saw this after posting: https://groups.google.com/d/msg/vim_dev/oRXcsh3NXgc/VlZf7RQ4AgAJ

[jamessan]

If performance is an issue, couldn't the path be resolved the first time v:progpath is accessed?

That only works if the required information to resolve the location of the binary is stored at startup.

Just saw this after posting: https://groups.google.com/d/msg/vim_dev/oRXcsh3NXgc/VlZf7RQ4AgAJ

That makes v:progpath slightly more reliable, but it's still quite easy for the path to be incorrect, which makes it useless to the user. I'll post a PR soon.

[xylix]

Could be interesting to have CI history and regression tests on neovim startuptime by itself and maybe with some popular plugin configs. To have a real-world integration "performance test".

Besides that this :CheckStartup would be interesting. Is anyone working on making this into a PR?