Slow performance: normal?

[hsnyder]

I use binary releases of w64devkit (i.e. I don't build it myself) and I've noticed that many of the executables are substantially slower than on Linux. Grep -r can take a very long time. Find does as well. Even opening vim generally takes a couple of seconds, though I think that's only after a reboot (maybe windows defender needs to appease itself?).

• Is that normal?
• Is there something that I'm doing wrong, or that could do to speed it up? Or is this just windows being slow?

Thanks

[skeeto]

Your description is neither the intended nor typical behavior. Vim should start practically instantly. On all of my systems:

$ time vim -Nu NONE +:q

This indicates about 100–150ms to start and exit a "compatible" Vim. If it's taking much longer, your local system configuration is probably the cause (virus scanner, etc.). Simple shell commands (ls, cat, etc.) should feel as fast as they do elsewhere.

If "slower than on windows" you mean Linux, that is expected, though the differences should be minor. BusyBox prioritizes small and simple over fast, and so performance will never compare to GNU Coreutils. It makes no difference for ls, but you'll notice heavy-duty commands like recursive grep are slower on the same inputs. Windows is also generally slower at dealing with paths (e.g. opening files/directories), which particularly affects "find" and "grep -r". Console window performance is also poor, bottlenecking command that display lots of output (though many terminal emulators on Linux aren't much better).

I also compile with -Os, tipping optimization towards small and away from fast, though you'd have a hard time measuring a speed difference from -O2.

A warning for anyone benchmarking: Do not redirect to the NUL device in benchmarks, including the virtual /dev/null in busybox-w32. Due to an old msvcrt.dll bug (and still in UCRT!), the CRT treats NUL as a line-oriented device, like a console, which is probably not what you wanted to measure.