making nvim start up a little faster on windows

Started by viviridian, Mar 17, 2025, 09:21 AM

Previous topic - Next topic

viviridian

this weekend i was poking around windows performance (recorder|analyzer) and noticed that during nvim cold starts, a significant amount of time was spent doing single-threaded file opens that became cpu bound because windows defender wanted to synchronously scan my plugins' lua files first.

the usual recommendation from random people on the internet is to disable windows defender or add an exclusion for the nvim-data path but i wanted to see if i could do better.

currently i parked my writeup in README.md, not sure if that's gonna be the final spot for it. there are a couple graphs 📈

in summary, i wrote a native plugin in rust that loads early on and spins up one thread per physical core, then opens and closes all the lua files that are on the critical path for startup - front-loading the windows defender scan and reducing my cold start time from ~4.242 seconds to ~3.384 seconds, a roughly 20% improvement.  8)

snow

Now I'm curious how long Windows Defender "caches"(?) a scan for. I assumed it would either scan a file every time it was opened, or only when it was modified.

Also a bit OT, but I didn't know you could parse ETW files?? I've had quite a few cases of fighting with WPA to get info I wanted. I'm going to keep that in mind :omg:

viviridian

Quote from: snow on Mar 18, 2025, 06:46 AMAlso a bit OT, but I didn't know you could parse ETW files?? I've had quite a few cases of fighting with WPA to get info I wanted. I'm going to keep that in mind :omg:
yeah! i was thinking that would be a really convenient way to dump the list of files to preload, and it mostly was except for the part where I needed to do some arcane stuff to transform \\Device\\HarddiskVolume1\\... paths into ones that used drive letters


unfortunately I tried to build this plugin on my work pc today and nvim won't load it  :imcold: not sure why