5 ms·

My Faster Bash Startup (2020)

36 points by chmaynard 5y ago

deleted 5y ago
[deleted]
encryptluks2 5y 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 5y ago
  If you run ubuntu, disable all the call-home functions in /etc/update-motd.d to speed up your bash login session
  - ta988 5y ago
    I was wondering why Ububtu logins were always that slow. This is ridiculous.
- dang 5y ago
  Ok, we've consed My onto the title above. Thanks!
- adrian_b 5y 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 5y ago
200ms just for loading completions? :( fish avoids this with lazy-loading
- JoshTriplett 5y 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 5y 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 https://github.com/justjanne/powerline-go in the past.
chasil 5y 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 https://wiki.debian.org/Shell
- teddyh 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago
    `brew help` alone takes a truly prodigious amount of time for what it is.
CodeIsTheEnd 5y 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 5y ago
  Haha that's brilliant!
codr7 5y 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 5y 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/153d9cbb4a8620ebbe2f24c093ac404a38257fa4/.bashrc https://gitlab.com/victor-engmark/tilde/-/blob/153d9cbb4a862... [2] https://work.lisk.in/2020/11/20/even-faster-bash-startup.html https://work.lisk.in/2020/11/20/even-faster-bash-startup.htm...
shirro 5y 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

36 points by chmaynard 5y ago

deleted 5y ago

[deleted]

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 5y ago
If you run ubuntu, disable all the call-home functions in /etc/update-motd.d to speed up your bash login session
- ta988 5y ago
  I was wondering why Ububtu logins were always that slow. This is ridiculous.
dang 5y ago
Ok, we've consed My onto the title above. Thanks!
adrian_b 5y 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 5y ago

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

JoshTriplett 5y 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 5y 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 https://github.com/justjanne/powerline-go in the past.

chasil 5y 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 https://wiki.debian.org/Shell

teddyh 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago
  `brew help` alone takes a truly prodigious amount of time for what it is.

CodeIsTheEnd 5y 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 5y ago
Haha that's brilliant!

codr7 5y 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 5y 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/153d9cbb4a8620ebbe2f24c093ac404a38257fa4/.bashrc https://gitlab.com/victor-engmark/tilde/-/blob/153d9cbb4a862... [2] https://work.lisk.in/2020/11/20/even-faster-bash-startup.html https://work.lisk.in/2020/11/20/even-faster-bash-startup.htm...

shirro 5y 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