关于bash和dash的速度是否有具体的数字？
根据这篇文章， dash被选为/bin/sh因为bash较慢： Dash为/ bin / sh
是否有快速dash速度的具体数字？
如果你使用bash而不是dash来启动Ubuntu需要多长时间？
上述链接的论点今天仍然有效吗？ 对于后台：system-v init使用了很多shell脚本，但systemd却没有。
这个问题与合成基准的速度无关。 这是最终用户的整体显着优势。 关于破折号与bash速度的综合基准并没有回答这个问题。
此测试不代表启动过程，但您可以通过制作一个小测试脚本来尝试自己，我称之为shspeed ：
$ cat shspeed for a in `seq 10000`; do ( :; ); done
这只是一个接一个地分配10000个子壳。 现在用bash运行它，并使用短划线和时间：
$ 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
因此，我的硬件上的速度要快得多，这是一款约1年的戴尔XPS 13 9365.你可以想象它在低端硬件上有更大的不同。 此外，此测试仅涉及for循环并生成子shell。 也许对于某些测试，结果将更加重要。
当然，你可以忽略它，并说你不关心产生10000个子shell的速度有多快。 好吧，有些人似乎在乎:)
对于您的特定启动过程，它可能不会产生任何明显的差异。 如果您使用/bin/bash作为/bin/sh并使用秒表测量差异，我不会发现问题。
请查看@wjandrea的这些链接，了解有关此事的详细说明： https ：//wiki.ubuntu.com/DashAsBinSh， 与dash相关联的重点是什么？
系统时的壳速度
在你修改了你的问题后，听起来更像是你对哪个shell更快感兴趣，但更多的是为什么我们仍然坚持让启动过程快一半（或者更快），特别是现在我们没有使用shell脚本我们在sysv-init是标准时所做的相同程度。
由于我没有参与Ubuntu的政治，我会尝试给出一个答案，因为它在我看来：
-
如果你只需要使用符号链接到另一个shell就可以快速制作半秒，这是值得的。
-
拥有默认的shell什么都不做，但POSIX要求默认shell做的事情是有意义的，以保持可移植性。 想象一下，一个发行版在init脚本中使用了另一个发行版没有的bashfunction。
-
（d）还增加了灰烬，以便能够在标准脚本中修复基础，并在将来避免使用它们。
/bin/sh是一个商定的标准，大型基础设施依赖于它。 没有什么我想用具有更大代码库的东西替换不需要的function。 -
使用较少的CPU周期和内存总是值得的。 甚至systemd单元通常在后台运行shell脚本。
所有这些可能与普通用户无关，但间接得到的是整体更稳定的分布。
为什么不打击？
这更像是一种观点：我个人绝不会选择破折号。 它只提供非常基本的结构。 对于更大的软件，我宁愿选择bash或zsh（或者根本不选择shell）。 我可能想要使用哪些function：高级参数扩展，shell算术，数组，或许更多。
这不应该发生在主要用于启动守护程序或安装软件的脚本中。 这些应该使用最少的指令集并保持脚本的可读性和简单性。 但如果他们能够获得所有bash的优点，那么很可能会发生。
/bin/sh应主要用于在合理方便的环境中运行外部程序，而不是用于复杂的软件系统。
摘要
/bin/sh ，由dash实现，带来了POSIX兼容的快速和稳定的脚本语言，可以很好地作为系统shell脚本的标准和默认解释器。 永远不会牺牲这些属性以支持便利function。
从程序员的角度来看，它实现了“做一件事，做得好”的口号。
它主要不是优化，而是职责分离。
它已经存在，所以不需要额外的努力来保持它。
用最终用户帽子来看待这个问题提出了一个问题：什么样的最终用户？ 桌面用户可能并不在乎，但他们仍然可以从更稳定（也许更快一点点）的分发中受益。 软件包维护人员会非常关注，而这些软件包可以从一个可靠的系统解释器中获益，该系统解释器具有一组小的，定义良好且经过良好测试的特性。 程序员不应该关心，因为他们可能不会在/bin/sh 。
PS：bash二进制文件几乎是dash二进制文件大小的10倍！