Closed siduck closed 2 years ago
tested with https://github.com/norcalli/profiler.nvim
startify does a lot more than dashboard, this is comparing apples to oranges. most of the time is spent doing I/O for the most recently opened files sections.
i haven't compared performance between alpha-nvim's dashboard theme and dashboard-nvim, but between the startify theme and vim-startify drawing the screen is slightly faster in alpha
comparing the dashboard theme with dasbhoard.nvim:
Config for alpha-nvim took 0.277057ms
...
VimEnter autocommand 7.19 ms
VimEnter autocommand 8.22
dashboard.vim 0.23ms
measured with nvim --startuptime
and PackerProfile
on my machine they are comparable, sourcing alpha is 0.05ms slower and drawing is ~1 ms faster. but i'm also using https://github.com/lewis6991/impatient.nvim
i'll see what i can do about shaving more time off loading alpha, but i've already looked in many corners for optimizations i could make.
i think your profiling is not measuring sourcing the dashboard.nvim vimscript, actually. that seems like it's only profiling how long it takes to require
your config, which presumably just sets some global variables
i think your profiling is not measuring sourcing the dashboard.nvim vimscript, actually. that seems like it's only profiling how long it takes to
require
your config, which presumably just sets some global variables
you were right, I tried --startuptime and dashboard's startuptime :
But I dont see alpha if the profiling done with --startuptime
yes, vim --startuptime doesn't measure lua plugins. and profiling your lua plugins will not measure the time to source vim plugins. you have to use 2 profilers, one for lua and one for vimL
But yea one thing Ive seen is that the overall startuptime is less when dashboard-nvim is used (used --startuptime)
what does your alpha config look like
what does your alpha config look like
its the default one
require("alpha").setup(require("alpha.themes.dashboard").opts)
ok, there is a lot of variance here, so it's hard to tell exactly what's happening just by looking at your --startuptime output. i will investigate this more later
ok, with no impatient.nvim even, this plugin is decisively faster on my machine
(no config)
use {
"~/Dev/alpha-nvim",
config = function () require("alpha").setup(require("alpha.themes.dashboard").opts) end
}
the inbuild --startuptime doesnt show the bar graph! how did you get it :O
https://github.com/dstein64/vim-startuptime ! it's a cool plugin.
i think there may be something else going on here, like maybe require
in nvim is slow on a mechanical drive, or maybe luajit generates worse machine code for a pentium than vimL's interpreter. mysterious
profiling using https://luarocks.org/modules/luarocks/luaprofiler didn't turn up anything suspicious either. most of the expensive functions have to do with drawing (which would fall under VimEnter
)
ok, i think i will write a minimal vimrc and make a branch with some debugging profiling stuff and have you run it later, if you're willing
can you try using nvim's built in startuptime flag? vim-staruptime keeps showing different startuptimes every time i run :St
try nvim --startuptime dashboard
nvim --startuptime alpha
i think there may be something else going on here, like maybe
require
in nvim is slow on a mechanical drive, or maybe luajit generates worse machine code for a pentium than vimL's interpreter. mysterious
probably , I have a low end pentium machine with a hdd , so the startuptime difference is usally noticeable.
vim-staruptime just calls nvim --startuptime
internally, if you run nvim --startuptime prof
you will see that the startup time is different every time. that's why the plugin allows you to average the startup time over a number of samples. the results are more or less the same for me when i run it from the command line
tangentially: i don't actually know why the startup time is different every time, if i had to guess it's just branch prediction, cache misses, maybe sometimes you just get unlucky and the scheduler doesn't allocate resources to vim, idk. another mystery
@siduck76 ok i figured out how to do a minimal vimrc for this. i have incidentally been pushing a bunch of minor performance improvements. i'm curious if any of them fixed the startup time issues on your machine
@goolord yes it reduced 10ms
@siduck there is a new option which might improve things for you https://github.com/goolord/alpha-nvim/commit/7ceb62ed560d7989585732728240db3ebffc5692
lmk if you get the time to test it
also the new should_skip_alpha
heuristics are a little more accurate so plugins like https://github.com/dstein64/vim-startuptime will more faithfully represent the real world, which could be helpful since it can collect multiple samples
@goolord its fixed now
hi! I had used dashboard-nvim before and it was quite fast and written in vimscript . I have a low end machine with pentium cpu so the startuptime matters for me!
alpha :
dashboard-nvim :