This article implicitly conflates the interactive shell with the shell that you use for scripting. On Ubuntu, /bin/sh is dash, which is lightweight and starts quickly, whereas the default interactive shell is bash. On FreeBSD, /bin/sh is a POSIX shell (and some people replace it with /rescue/sh, which is statically linked and starts even faster) and most people install something like zsh or bash as their interactive shell.

There’s no reason not to have a fast-launching shell for scripting and a slower one for interactive use.

Why not just add shebang lines to your shell scripts?

I think needing to profile your shell is mostly a zsh thing. Sure some of the external binaries add time, but interactive shell startup is just much easier to bog down with zsh. I spent years and tried many of the different optimizations, but it’s an ongoing battle.

I switched to fish a few years ago and haven’t looked back. Worrying about startup time is now a thing of my past.

Based on the title, I thought this was gonna be about maintaining a pool of shells, so that you always had one warmed up when you open a new window/tab/split.

Just what are you people putting in your interactive shell startups to make all this worthwhile?

openbsd$ time ksh -i -c exit
    0m00.00s real     0m00.00s user     0m00.01s system

this article doesn’t even mention pdksh, but it smokes all the other examples

An obvious question is: which shell is used to run sub-commands? Surprisingly, there is no simple answer to this, and different programs use different shells to run sub-commands. Some use the contents of the $SHELL environment variable; some use the shell set in the user database (i.e. /etc/passwd and friends); and some use a hard-coded shell (e.g. /bin/sh). In most cases, $SHELL and the shell in the user database are the same, often a “big” shell like bash, fish, or zsh. In many of the cases I care about, my non-interactive commands are run with one of these big shells, so the overhead of them is something I care about.

I don’t feel like this is accurate ? What kind of Unix system are you using?

• On say Debian, every script has a shebang line, usually #!/bin/sh
• Scripts in tarballs and git repos will often have #!/bin/bash or similar
• If there’s no shebang line, the shell will use /bin/sh (i.e. shells invoking shell scripts without shebangs have a special rule)
• The system() call in libc is defined by POSIX to use /bin/sh. So if you do os.system() in Python, it will use /bin/sh.
• GNU make will use /bin/sh unless you override it with $SHELL I believe.
• Ninja parses the command lines and makes its own argv array; it doesn’t need to use a shell at all.

On say Debian I’ve never heard of any case where the kind optimization you’re suggesting matters. But maybe that’s because Debian switch /bin/sh to dash a long time ago.

Though I seem to remember that they actually couldn’t measure the performance benefit from switching /bin/sh from bash to dash … there were some people upset about that. The main thing was that bash was viewed as sort of bloated and unreliable, and badly documented.

I guess to be more specific, my shell on Debian is /bin/bash according to /etc/passwd.

But I don’t anticipate any speedup at all by switching it to /bin/sh, even though dash (which is /bin/sh) is slightly faster than bash – and honestly I’m not sure that’s even true in the non-interactive case! They both seem to take 1ms or less.

Where would switching to /bin/sh make a difference? Most things that need to be fast already use /bin/sh without me configuring it – on Debian, but I think that’s true on all Unixes, just because of the way shebang lines and system() work.

My zsh starts in 14ms :)

I spent a bunch of time back in 2015 to make it fast: https://github.com/stapelberg/configfiles/commits/master/zshrc?after=8cbbf81da4ea02cb3de551f150d34f34cfda14c0+69 contains the commits (Nov 11 + Nov 12), and it was definitely worth it!

Fish shell with a lean config, ~13ms outside of a git repo, ~15ms inside a big git repo (where I get a prompt with the status of the repo).

I removed conda initialization stuff from the config some time ago because it slowed it down significantly.

This article is a good prompt to take a gander at your shell rc file, which is always worth doing from time to time - I solved this problem another way though: caching! I keep a staged shell process in the background, and when I start a terminal what I’m actually doing is picking up the staged process, so the startup time is 0 (aside from window creation).

It’s hard enough getting scripts to work in a single version of a single Unix shell; keeping extremely subtle shell differences in short-term memory seems like a waste.

I don’t think the non-interactive shell ends up being POSIX-ly correct. It is not strictly /bin/sh, because RegExp matching with [[ is a Dash/Bash/Zsh/etc. feature.

I was glad to see someone commented on my favorite shell fish! As a philosophical aside , how come so many people like ZSH? I haven’t really bothered with it because fish kind of does everything that I need.

According to hyperfine, my bash takes ~13ms, with the fancy prompt.

I wrote the prompt in Zig so that it’s easy to ensure that there’s no allocations, only one write call, etc. But I never really measured it like this. Seems okay, considering all the other stuff that’s in there.

For a hot-cache time, I get

$ (repeat 20 ZSH_TIME_STARTUP= zsh -lic exit)|& cstats -m3
0.025019 +- 0.000023 seconds

But I do zcompile my zcompdump file after profiling revealed that as a major source of time.

EDIT: But in non-interactive use with an empty environment, statically linked dash starts up in only about 210 +- 16 microseconds. So, you know 125X more for all that Zsh interactive sugar (which I do love!).

I really like having information about git status in my prompt (if I’m in a git repository), but that can slow down “time to next prompt” to a noticeable degree (especially in large git repos). The linked article recommends removing the information from your prompt and just running commands (e.g., git status) in the shell. That will definitely fix the delay, but as an alternative I recommend that people look for async solutions. I’m currently using woefe/git-prompt.zsh to display git status in zsh, and it completely removes the drag from git lookups. (I’ve also seen solutions for zsh that use a daemon or a cache, but I haven’t investigated those.)

Also, again for zsh, a good tool for timing how long it takes to get a new prompt on zsh is zsh-prompt-benchmark. It can be useful if you are tweaking things and want to check for improvement.

Nushell for me on a low-end VPS (HDD, 2 vCores) takes about 40ms. That’s also with Starship enabled.

Yayy.

Both phone and my NixOS computers are under 100ms. Laptop around 30ms, Termux at about 50ms.

I use bash, custom vanilla PS1 (\u@\h \w $?\$ \[$(tput sgr0)\])

Bash takes less than 40 ms on my laptop with things like Starship, direnv, and shared history between terminals configured. Not bad!

A major factor is probably that all those tools which want to be loaded in every Bash shell are instead loaded only in the relevant shell.nix.

Shaved 20ms of mine, from:

$ hyperfine -N -w 10 --min-runs 500 'bash -i -c exit'
Benchmark 1: bash -i -c exit
  Time (mean ± σ):      41.9 ms ±  45.2 ms    [User: 29.3 ms, System: 10.6 ms]
  Range (min … max):    19.3 ms … 600.1 ms    500 runs

to

$ hyperfine -N -w 10 --min-runs 500 'bash -i -c exit'
Benchmark 1: bash -i -c exit
  Time (mean ± σ):      22.0 ms ±  22.9 ms    [User: 15.3 ms, System: 4.0 ms]
  Range (min … max):    12.8 ms … 254.0 ms    500 runs

Maybe I can enhance it a bit, but that’s not 1s neither :)