6

According to this article, dash was chosen as /bin/sh because bash is slower: Dash as /bin/sh

Are there concrete figures for how much faster dash is?

How much longer does it take if you use bash instead of dash to boot Ubuntu?

Do the arguments of the above link still count today? For background: system-v init used a lot of shell scripts, but systemd does not.

This question is not about speed in a synthetic benchmark. It is about the overall noticeable benefit for the end user. A synthetic benchmark about the speed of dash vs bash does not answer the question.

17
  • 2
    /bin/dash was invented because the actual Bourne shell and Korn shell weren't open-source at that time( late 80s early 90s) , and were proprietary. – Sergiy Kolodyazhnyy Jul 25 '18 at 20:34
  • 1
    @SergiyKolodyazhnyy but bash existed already when ash was made. – Sebastian Stark Jul 25 '18 at 20:34
  • Also, boot process involves an init system, which is what actually brings up services. Shells are for commands/automation via scripts, and may be used as part of init system but don't play that much role in boot process itself – Sergiy Kolodyazhnyy Jul 25 '18 at 20:37
  • @SebastianStark Existed, sure did. But there's variety of reasons why there's need for actually a Bourne shell alternative. One, POSIX compliance. Two, bash is a GNU thing, which is fine on Linux because most of Linux community came out of GNU projects at first, but wasn't as welcome on BSD projects. And again dash itself is Debian implementation of ash (Almquist) shell, which originally was a Open BSD thing – Sergiy Kolodyazhnyy Jul 25 '18 at 20:41
14
+50

This test is not representative for the boot process, but you can simply try out yourself by making a little test script, I called it shspeed:

$ cat shspeed
for a in `seq 10000`; do ( :; ); done

This simply forks 10000 subshells one after another. Now run it with bash and with dash and time it:

$ time dash shspeed
dash shspeed  0,70s user 0,33s system 107% cpu 0,965 total

$ time bash shspeed
bash shspeed  1,59s user 0,76s system 108% cpu 2,180 total

So, it's a lot faster on my hardware, which is a ~1 year old Dell XPS 13 9365. You can imagine that it makes a bigger difference on low end hardware. Also, this test is only about a for loop and spawning a sub shell. Perhaps for some tests the results will be even more significant.

Of course, you can ignore that and say you do not care about how fast it is to spawn 10000 sub shells. Well, some seem to care :)

For your particular boot process it probably would not make any noticeable difference. I don't see a problem if you use /bin/bash as /bin/sh and measure the difference with a stop watch.

Please check these links from @wjandrea for detailed explanation of the matter: https://wiki.ubuntu.com/DashAsBinSh, What is the point of sh being linked to dash?

Shell speed in times of systemd

After your modified your question it sounds more like you are not so much interested in which shell is faster, but more why we still stick to making the boot process half a second faster (or so), especially now that we are not using shell scripts anymore to the same extent we did when sysv-init was the standard.

Since I am not involved in the politics of Ubuntu I will try to give an answer as it appears to me:

  1. If you can make something half a second faster by simply using a symlink to another shell, it's worth it.

  2. Having the default shell do nothing but what POSIX requires the default shell to do makes sense in order to keep things portable. Imagine one distribution uses a bash feature in an init script that another distribution does not have (yet).

  3. (d)ash was also added to be able to fix bashisms in standard scripts, and also to avoid them in the future. /bin/sh is an agreed on standard, something big big infrastructures are depending on. Nothing I would like to replace with something having a much larger code base with unneeded features.

  4. Using less CPU cycles and memory is always worth it. Even systemd units often are running shell scripts in the background.

All this is likely irrelevant for the average user, but indirectly what they get is an overall more stable distribution.

Why not bash?

This is more of an opinion: Personally I would never choose to script in dash. It offers very basic constructs only. For a bigger piece of software I would rather choose bash or zsh (or something not shell at all). Which features I would want to use perhaps: advanced parameter expansions, shell arithmetics, arrays, maybe some more.

This should not happen in scripts primarily used for starting up daemons or installing software. Those should use a minimum set of instructions and keep scripts readable and simple. But it would likely happen if all the goodness of bash would be available to them.

/bin/sh should be mainly for running external programs in a reasonably convenient environment, not for complex software systems.

Summary

/bin/sh, as implemented by dash, brings a POSIX compatible fast and stable scripting language, that works well as the standard and default interpreter for system shell scripts. These properties will never be sacrificed in favour of convenience features.

From a programmer's point of view it fulfills the mantra of "do one thing and do it well".

It is not primarily an optimisation, but separation of duties.

It is already there, so it is no additional effort to keep it.

Looking at this with end-user-hat on poses the question: what kind of end-user? A desktop user couldn't care less, but they would still benefit from a more stable (and perhaps tiny bit faster) distribution. A package maintainer would care a lot, and those benefit from a reliable system interpreter with a small, well-defined and well-tested set of features. A programmer shouldn't care, as they likely do not develop in /bin/sh.

PS: the bash binary is almost 10 times the size of the dash binary!

10
  • 1
    Braces don't spawn a subshell. Parentheses do. See man bash. – wchargin Jul 26 '18 at 0:31
  • 2
    When spawning subshells with for a in $(seq "$1"); do ( :; ); done, my results are: 1.306s for dash, 4.446s for bash (10000 iterations, best-of-3 timing, 2014 T440s). – wchargin Jul 26 '18 at 0:32
  • You say "the bash binary is almost 10 times the size of the dash binary!". I say "Optimize later". – guettli Jul 26 '18 at 10:00
  • @wchargin how embarrassing I confused that. I fixed the answer, and reduced to 10000 rounds. Thanks! – Sebastian Stark Jul 26 '18 at 21:23
  • @SebastianStark "the bash binary is almost 10 times the size of the dash binary!" seems to be very important for you. I can't follow you. I am not working with an embedded device. What is the end user benefit? I guess the average linux user (or application) does not see any difference. You are right.: the Bash is bigger. But if the size has no drawback, then it is not important for me. What do you think? – guettli Jul 27 '18 at 7:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.