Are there concrete figures on the speed of bash vs dash?

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.

Solution 1:

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!