My Faster Bash Startup (2020)

https://danpker.com/posts/faster-bash-startup/

by chmaynard • 5 years ago

36 20 5 years ago

Should be retitled My Faster Bash Startup. This had nothing to do with Bash itself and everything to do with the user.

The big one is that Homebrew is abnormally slow in general and they had multiple commands running homebrew in subshells.

grepfru_it• 5 years ago

If you run ubuntu, disable all the call-home functions in /etc/update-motd.d to speed up your bash login session

ta988• 5 years ago

I was wondering why Ububtu logins were always that slow. This is ridiculous.

dang• 5 years ago

Ok, we've consed My onto the title above. Thanks!

adrian_b• 5 years ago

I have never tried to measure the startup time for interactive bash, because my .bashrc only has a large number of environment variables and of command aliases, so I do not see any visible delay at startup.

However I have tried to benchmark bash against zsh, to see if one of them is faster.

The benchmark was inconclusive, because I have tried 2 scripts, but the execution times were essentially the same for both bash and zsh.

The 2 scripts invoked a small shell script on each of about ten thousand files and various file attributes were tested and compared in some shell conditional expressions.

Because the times were the same for bash and zsh, it is likely that the file operations dominated the execution time and not the shell startup time or the script interpretation, as I expected.

The shorter benchmark corresponded to an execution time of about 10 millisecond per shell script, so this is an upper limit for the bash startup time in non-interactive mode on my computer.

It is likely that the startup time was several times less.

In conclusion, the startup of bash in non-interactive mode, when it does not source .bashrc or other scripts, is no more than a few millisecond.

It is clear that someone who wants bash to start fast should be able to reach a startup time much, much less than a second.

krobelus• 5 years ago

200ms just for loading completions? :( fish avoids this with lazy-loading

JoshTriplett• 5 years ago

bash-completion does this too, these days. It doesn't load the completions for a command until the first time you invoke completion on that command.

watermelon0• 5 years ago

It's amazing how slow shell prompts can be when you enable just a few addons. It can easily take a few seconds to show a prompt.

I've had good results with https://github.com/justjanne/powerline-go in the past.

chasil• 5 years ago

Debian displaced bash as root's default, and now uses the Almquist shell for performance reasons.

I would be curious if mksh is also faster. ksh93 also claims great performance increases, but it is no longer (well) maintained.

"Therefore, many interactive features are not present in Dash, making it faster and more memory efficient than Bash."

https://wiki.debian.org/Shell

teddyh• 5 years ago

Debian displaced bash as root's default

Um, no? Debian changed what /bin/sh is, which is what many shell scripts use, especially those startup scripts used by sysvinit. The shell of the root user remains, AFAIK, /bin/bash.

b112• 5 years ago

Indeed. Bash was used for sh emulation before, the reason given for the change to dash was that sh emulation was more correct with it.

(I think it allowed bashisms even when called as sh)

lhoursquentin• 5 years ago

I would be curious if mksh is also faster. ksh93 also claims great performance increases, but it is no longer (well) maintained.

mksh `printf` is not builtin, so if the script makes heavy use of it then it tends to be slower than bash.

ksh is very interesting because it has the ability to avoid spawning new processes on most command susbstitutions, making it usually much faster than all other POSIX shells.

But again this depends heavily on what the script being executed is doing, here's a highlight of what I described:

  $ time mksh -c 'for i in $(seq 1000); do printf $(printf $(printf $(printf hello))); done' > /dev/null
  
  real    0m2.121s
  user    0m1.321s
  sys     0m0.875s

  $ time ksh -c 'for i in $(seq 1000); do printf $(printf $(printf $(printf hello))); done' > /dev/null
  
  real    0m0.013s
  user    0m0.008s
  sys     0m0.005s

  $ time dash -c 'for i in $(seq 1000); do printf $(printf $(printf $(printf hello))); done' > /dev/null
  
  real    0m0.311s
  user    0m0.279s
  sys     0m0.073s
  
  $ time bash -c 'for i in $(seq 1000); do printf $(printf $(printf $(printf hello))); done' > /dev/null
  
  real    0m0.664s
  user    0m0.538s
  sys     0m0.186s

onedognight• 5 years ago

TL;DR This post should be titled “`brew --prefix <formula>` is slow, but I won’t try and fix it; instead I’ll hard-code some paths”.

mrHedgehog• 5 years ago

I've found that `brew` itself is quite slow. I think the problemis just with how brew does it's package management. I'm not going to complain about it, because it's (IMO) better than MacPorts.

naniwaduni• 5 years ago

`brew help` alone takes a truly prodigious amount of time for what it is.

CodeIsTheEnd• 5 years ago

And if you want an increasingly slower bash startup, you can add the following to your coworker's .bashrc/.bash_profile if they keep forgetting to lock their screen when they go to grab a snack:

    echo 'sleep 0.01' >> ~/.bashrc # or ~/.bash_profile

bobowzki• 5 years ago

Haha that's brilliant!

codr7• 5 years ago

Me thinks I'm spending too much time on HN lately.

On the other hand, thank God it wasn't that kind of startup.

l0b0• 5 years ago

tl;dr: If you're seeing unreasonably short startup times, try `hyperfine 'bash -i'` instead.

Funny, I thought my startup time was going to be ginormous, considering I've literally committed to it 203 times so far[1]. Nope, 1.4 to 4.3 ms.

Update: Eyeballing the startup time it's definitely over a second, so I'm guessing OP is measuring something different from what I'm seeing. `hyperfine bash` is also below 5 ms, so I'm not sure how to measure actual startup time. `hyperfine 'bash -i'` does the trick, showing ~650 ms startup times. Turns out another blogger found this already[2] :)

[1] https://gitlab.com/victor-engmark/tilde/-/blob/153d9cbb4a862...

[2] https://work.lisk.in/2020/11/20/even-faster-bash-startup.htm...

shirro• 5 years ago

Nearly 2s for a shell startup is ridiculous. I am starting to understand why the Apple fans are so excited about clawing back some performance with M1. My bash login shell is under 40ms on this cheap 4 year old i5 laptop. People must load some crazy stuff in their profiles

My Faster Bash Startup (2020)

Related Stories