Those little delays add friction. Not an intolerable amount, sure, but it’s there. While I switched to fish for other reasons, that alone would keep me from going back now.
A lot or most of that wasn't zsh being slow though, but oh-my-zsh calling out to external programs (like git to get powerline info and such) and them being slow.
And that's 40 C processes. "python empty.py" takes about 30ms to 40ms due to the interpreter startup time; empty C file is about 2ms, "sh empty.sh" is about 4ms.
Please think that "launching external programs is fast and modern computers are fast, so why worry about this?", and that's true, but it's also not. Add up a few dozen and turns out it's actually quite slow.
The nvm init was the worst of it, so now I have an alias for `$NVM_DIR/nvm.sh ] && \. "$NVM_DIR/nvm.sh" && \. $NVM_DIR/bash_completion` I just run manually before using nvm, rather than letting it slow me down half a second or whatever it was every time I open a new terminal.
It's worth poking around if things get slow enough to be a pain. There's a decent chance it's 1-2 things that you don't even care about all that much.
Its an asdf[2] rewrite, in rust, that can do most of the things nvm can
> --profile-startup=PROFILE_FILE > Will write timing for fish startup to specified file.