Bringing down my ZSH load times from ~3.1s to ~230ms

AprilArcus

How did I know it was going to be `nvm` before I clicked?

ricardobeat

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

basetensucks

Adopting https://github.com/marlonrichert/zsh-snap was probably the best decision I've made around zsh in the last five years.

tecoholic

Use mise and you will be in the micro-seconds region. https://arunmozhi.in/2024/09/06/replacing-pyenv-nvm-direnv-w...

jauntywundrkind

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.

jasonpeacock

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?

vivzkestrel

- 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

adrian_b

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).

kstrauser

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.