Use `noautocmd` when setting 'alpha' buffer local options

[echasnovski]

I've found a way to visibly reduce startup time with this plugin if setting local options is done with noautocmd. So it would become noautocmd silent! setlocal ....

Here considerable speedup is achieved because setting filetype=alpha might trigger a lot of FileType autocommands. In order to have a way for others to run autocommand after 'alpha' buffer is opened, you can issue your custom event with doautocmd (doautocmd User AlphaBuffer).

Didn't make a PR because wasn't sure if it would affect anything else.

[goolord]

i tried adding noautocmd and didn't see any effect in benchmarks, tbh if simply setting a filetype is enough to add a noticeable latency that seems like a user configuration issue. having the FileType autocmd is too useful for integration with other plugins i think

[echasnovski]

Well, I remember having quite big difference in overall startup time in real-world config (not sure how you benchmark). It might be negligible if there are not many FileType autocommands coming from plugins. The FileType autocommand can be replicated by issuing custom event, as I described. At least that is what I am doing in 'mini.starter' and this approach got quite significant speedup.

[goolord]

i just use my daily driver config and average a bunch of --startuptimes, yeah i don't have something like vim-polyglot installed or something so maybe it's only not so bad for me

[goolord]

the fact that you did something similar for mini.starter makes me more comfortable about using it, after testing it didn't seem to break any autocmds that someone might already have set up for this plugin so i just pushed it at https://github.com/goolord/alpha-nvim/commit/658aff2788b076ddbd919cfb49c943d7296301fe

if it breaks something for someone i'll just revert it or set up a migration plan nbd ¯_(ツ)_/¯

thanks for the tip :black_heart:

[goolord]

it broke things so it was reverted, but it was reintroduced as opt in here https://github.com/goolord/alpha-nvim/commit/7ceb62ed560d7989585732728240db3ebffc5692

[echasnovski]

I was curious to put things in perspective, so I slightly modified my benchmarking setup to measure the difference between 'without noautocmd' and 'with noautocmd' settings. When effect is small and barely noticeable by human eye, making repetitive measurements is the key.

So there are five configurations here:

• Empty one, for reference.
• Two with startify theme. They have same code except startify.opts.opts.noautocmd is false and true ('with-noautocmd' case).
• Two with dashboard theme. They have same code except dashboard.opts.opts.noautocmd is false and true ('with-noautocmd' case).

I reran on different machine with 100 repetitions in non-focused window in background, so results are not as accurate as they might be. Here they are:

init file	median	mean	stdev	minimum	maximum
empty	51.9ms	52.0ms	1.1ms	51.2ms	62.0ms
startify-alpha	57.7ms	57.8ms	0.8ms	56.9ms	64.3ms
startify-alpha_with-noautocmd	56.1ms	56.2ms	0.6ms	55.2ms	58.9ms
dashboard-alpha	55.5ms	55.6ms	0.9ms	54.5ms	62.8ms
dashboard-alpha_with-noautocmd	53.8ms	53.9ms	0.6ms	53.0ms	57.2ms

Difference in 1.6-1.7 ms is not much, sure. But it is a decrease by ~47% for dashboard and ~28% for startify themes in terms of added time (compared to empty reference). I also saw consistently smaller median time for 'with noautocmd' variant when making some test runs with 10 repetitions.

I don't know the "true" underlying reason for why this is happening, but my initial profiling for 'mini.starter' showed that it was because of filetype=*** call.