bash 与 dash 的速度有具体的数字吗？

Question

根据这篇文章，dash被选为/bin/sh因为bash较慢：Dash as /bin/sh

有没有具体的数字来说明速度有多快dash？

如果使用bash而不是dash引导 Ubuntu需要多长时间？

上面链接的论点今天仍然有效吗？对于背景：system-v init 使用了很多 shell 脚本，但 systemd 没有。

这个问题与综合基准测试中的速度无关。它关乎最终用户的整体显着利益。关于 dash 与 bash 速度的综合基准测试并没有回答这个问题。

Answer 1

此测试不代表启动过程，但您可以通过制作一个小测试脚本来简单地自己尝试一下，我称之为shspeed：

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

这只是一个接一个地 fork 10000 个 subshel​​l。现在用 bash 和 dash 运行它并计时：

$ 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 循环和生成子外壳有关。也许对于某些测试，结果会更加重要。

当然，您可以忽略它并说您不关心生成 10000 个子外壳的速度。好吧，有些人似乎在乎:)

对于您的特定启动过程，它可能不会产生任何显着差异。如果您使用/bin/bashas/bin/sh并用秒表测量差异，我认为没有问题。

请检查从@wjandrea这些链接对此事详细的说明：https://wiki.ubuntu.com/DashAsBinSh，什么是SH点被链接到几许？

以 systemd 计算的 Shell 速度

在你修改了你的问题之后，听起来你对哪个 shell 更快不太感兴趣，但更多的是为什么我们仍然坚持让启动过程快半秒（左右），特别是现在我们没有使用 shell 脚本再到我们在 sysv-init 成为标准时所做的同样程度。

由于我不参与 Ubuntu 的政治，我将尝试给出我认为的答案：

1. 如果您可以通过简单地使用指向另一个 shell 的符号链接来使速度快半秒，那么这是值得的。

2. 除了 POSIX 要求默认 shell 做的事情之外，让默认 shell 什么都不做是有意义的，以保持可移植性。想象一下，一个发行版在 init 脚本中使用了另一个发行版（还没有）的 bash 功能。

3. (d) ash 也被添加到能够修复标准脚本中的 bashisms，并在未来避免它们。/bin/sh是一个商定的标准，大型基础设施所依赖的东西。我不想用更大的代码库和不需要的功能来替换。

4. 使用更少的 CPU 周期和内存总是值得的。甚至 systemd 单元也经常在后台运行 shell 脚本。

所有这些对于普通用户来说可能无关紧要，但他们间接获得的是整体更稳定的分布。

为什么不打？

这更多是一种意见：我个人永远不会选择用破折号编写脚本。它仅提供非常基本的构造。对于更大的软件，我宁愿选择 bash 或 zsh（或根本不是 shell 的东西）。我可能想使用哪些功能：高级参数扩展、shell 算术、数组，也许还有更多。

这不应发生在主要用于启动守护程序或安装软件的脚本中。这些应该使用最少的指令集，并保持脚本的可读性和简单性。但是，如果 bash 的所有优点都可供他们使用，这可能会发生。

/bin/sh 应该主要用于在合理方便的环境中运行外部程序，而不是用于复杂的软件系统。

概括

/bin/sh由 dash 实现，带来了一种与 POSIX 兼容的快速稳定的脚本语言，可以很好地作为系统 shell 脚本的标准和默认解释器。永远不会为了便利功能而牺牲这些属性。

从程序员的角度来看，它实现了“做一件事，把它做好”的口头禅。

它主要不是优化，而是职责分离。

它已经存在，因此无需额外的努力来保留它。

带着最终用户的帽子来看待这个问题提出了一个问题：什么样的最终用户？桌面用户不会太在意，但他们仍然会从更稳定（也许更快）的分发中受益。包维护者会非常关心，而这些人会从可靠的系统解释器中受益，该系统解释器具有少量、定义明确且经过良好测试的功能集。程序员不应该关心，因为他们可能不会在/bin/sh.

PS：bash 二进制文件几乎是 dash 二进制文件大小的 10 倍！