[abathur]

Are you sure it's loading history in there? My .zsh_history isn't completely empty, and when I run the same with 'history' swapped for 'exit' it doesn't print anything. (But this might have something to do with macOS default shell profile stuff.)

[bee_rider]

Actually, this seems like an interesting question. I don’t really see any reason why a shell must load the history file before the user starts typing. I mean, I usually don’t ^r immediately, so to speed things up it could:

* Load asynchronously

* Only have a barrier if I reverse-search.

Might be over-engineered, though.

[loeg]

zsh may very well be doing this, especially for any de-duplication index.

[loeg]

Not confident, no. But even running an interactive zsh manually and exiting as fast as humanly possible is within the same ballpark, modulo human reaction times.

  $ time zsh
  $ ^D
  zsh  0.14s user 0.04s system 80% cpu 0.219 total

It's just not an obstacle to spawning a new shell and using it.

[AdieuToLogic]

A way to ensure the zsh invocation behaves as a typical interactive shell is:

  time zsh --login -c 'logout'

Note use of logout instead of exit. In this context, logout ensures whatever combination of flags used results in a login shell.

See zshbuiltins(1).

[loeg]

On par with the first time.

  $ time zsh --login -c 'logout'
  zsh --login -c 'logout'  0.03s user 0.01s system 99% cpu 0.037 total

Whenever I've had noticeably slow zsh startup times in the past, it was almost always some plugin/extension doing something very dumb (e.g. stuff like full 'git status' in a large repo -- just takes time); not the history management.

[AdieuToLogic]

> On par with the first time.

This was my experience as well. The --login flag was recommended in order to address concerns raised by @abathur.

> Whenever I've had noticeably slow zsh startup times in the past, it was almost always some plugin/extension doing something very dumb (e.g. stuff like full 'git status' in a large repo -- just takes time); not the history management.

Great point.

Unfortunately, my limited research suggests tracking down which plugin or extension is the root cause is a manual effort starting with the contents of the canonical zsh initialization files (often named .zlogin, .zprofile, .zshenv, and .zshrc).

[tough]

nvm plugin used to be really bad!

i think you can debug-trace loading time putting some commands on your zshconfig

[bee_rider]

Is .14s noticeable? That’s more than a couple frames at 60fps.

I mean, this might seem really bizarre to worry about, but some folks use tiling window managers and just expect to immediately start typing once the “new terminal” key is hit…

Actually this has been slightly annoying me lately after making my system pretty. I added some fancy compositor stuff and now if I do “open terminal,” “exit” the computer complains that it doesn’t know what xit means. Not a big enough problem to fix though.

Edit: huh, actually playing with it this seems to be 99% the fault of the terminal emulator anyway, not the shell or my silly special effects.

[AdieuToLogic]

> Is .14s noticeable?

Unless the system is under memory pressure, most shell initialization will read from in-memory OS file caches and not be noticeable as you note.

Where significant delays are often seen is when a seemingly innocuous extension uses network-based or some other heavy file system I/O commands (such as a "find $HOME -type f" type of thing).

[loeg]

Even under memory pressure, it's not a ton of SSD IO time (e.g., mine is 5 MB).

[umbra07]

This is why I switched to `fish`. Customizing zsh to achieve feature parity with fish (along with the tide prompt) made zsh veryyyy slow. It's entirely possible that there's some sort of optimized loader for zsh out there that ameliorates this, but I just couldn't be bothered.

[loeg]

The 0.14s includes me noticing zsh has started and typing ^D.