13 comments

[ 3.7 ms ] story [ 30.1 ms ] thread
How did I know it was going to be `nvm` before I clicked?
Having gone through the same experience, I suggest dropping fnm as well; I don’t recall what exactly causes it, but it will eventually slow down too.

I’ve been using mise [1] to manage node versions since with zero issues.

[1] https://mise.jdx.dev

My mini-story: I'd switched to zimfw which does a ton of caching, precompiling. It benches very well versus other zsh frameworks. But something was still taking almost a second for me, every time. https://github.com/zimfw/zimfw

zprof helped me and the LLM profile and we found it was one plugin, which wasn't really intended specifically for zim. Fixed that! https://github.com/lipov3cz3k/zsh-uv/issues/2

Man it feels so good having shells just open so lightning fast.

Huh, I just ran the same timing command for my fish shell (with starship prompt) and got 168ms.

What all is happening in the Zsh profile?

- none of your blog links work https://iam.mt/blog-changes/

- also you should put a list of all your article. (titles only) on some page called /archive or something

- i really dont want to scroll 5000 pages to see the last 20 articles you wrote

- just a suggestion from a ui / ux perspective

Even the final starting time for zsh from TFA is quite bad.

On a 6-year old desktop PC with a Ryzen CPU, an interactive zsh starts in 20 ms and a login zsh starts in 60 ms.

The configuration file for the interactive zsh, i.e. "~/.zshrc", has 75 lines and it configures completions (in the default manner added to ~/.zshrc by compinstall), binds some keys, sets umask and some shell options and defines a bunch of environment variables (including the prompt) and of command aliases.

I do not see what else would be needed, which could increase the starting time.

My login zsh takes 40 ms longer because I do not use a GUI login, but the classic CLI login, so the login zsh checks if a GUI desktop session is running and if not it starts the session (obviously, the 60 ms login zsh starting time is for when the GUI session is already running).

I have a complex fish shell configuration with ~100 autoloaded functions and about 180 lines across config.fish and a dozen conf.d/ files.

On my system, hyperfine says fish loads in about 85ms:

  Benchmark 1: fish -il -c exit
    Time (mean ± σ):      85.0 ms ±   3.3 ms    [User: 50.1 ms, System: 31.4 ms]
    Range (min … max):    82.9 ms … 101.1 ms    28 runs
And that's without giving up a single thing in the name of quickness. Stick with zsh if you want, but understand that there are tradeoffs. And for the fish end of those tradeoffs: 1) most command lines work identically between fish, zsh, and bash; 2) where they don't, the fish version is nearly always more pleasant and obviously correct for interactive use; and 3) you don't have to uninstall bash, ya know — you can still `curl foo | sh` to run some random script off the net if you feel the desire. Your existing stuff doesn't stop working.
Because of the performance and stability issues I moved to fish for 1 year and I like it even more, it's syntax, functions it's tab completions, for some reason with zsh I always had an issues, my bad, but fish work perfectly out of the box.
Nobody who uses nix has ever had such problems.