Есть конкретные цифры по скорости bash против dash?

Этот тест не является репрезентативным для процесса загрузки, но вы можете просто попробовать себя, сделав небольшой тестовый скрипт, я назвал его shspeed:

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

Это просто разветвляет 10000 подоболочек один за другим. Теперь запустите его с помощью bash, dash и time:

$ 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 год Dell XPS 13 9365. Вы можете себе представить, что это имеет большее значение на младшем оборудовании. Кроме того, этот тест только о цикле for и порождении вложенной оболочки. Возможно, для некоторых тестов результаты будут еще более значительными.

Конечно, вы можете проигнорировать это и сказать, что вас не волнует, как быстро появится 10000 субоболочек. Ну, некоторые, кажется, все равно:)

Для вашего конкретного процесса загрузки это, вероятно, не будет иметь никакого заметного значения. Я не вижу проблемы, если вы используете /bin/bash как /bin/sh и измерить разницу с секундомером.

Пожалуйста, проверьте эти ссылки на @wjandrea для подробного объяснения вопроса: https://wiki.ubuntu.com/DashAsBinSh, Какой смысл sh быть связанным с dash?

Скорость оболочки во времена systemd

После того, как вы изменили свой вопрос, звучит так, что вас больше не интересует, какая оболочка быстрее, а больше - почему мы все еще стремимся ускорить процесс загрузки на полсекунды (или около того), особенно сейчас, когда мы не используем сценарии оболочки больше в той же степени, что и мы, когда sysv-init был стандартом.

Поскольку я не участвую в политике Ubuntu, я постараюсь дать ответ так, как мне кажется:

1. Если вы можете сделать что-то на полсекунды быстрее, просто используя символическую ссылку на другую оболочку, это того стоит.

2. Оболочка по умолчанию не делает ничего, кроме того, что POSIX требует, чтобы оболочка по умолчанию имела смысл для сохранения переносимости. Представьте, что один дистрибутив использует функцию bash в скрипте инициализации, которого нет в другом дистрибутиве (пока).

3. (d) также был добавлен пепел, чтобы иметь возможность исправлять ошибки в стандартных сценариях, а также избегать их в будущем. /bin/sh это согласованный стандарт, от чего зависит большая инфраструктура. Ничего, что я хотел бы заменить чем-то, имеющим гораздо большую базу кода с ненужными функциями.

4. Использование меньшего количества циклов процессора и памяти всегда того стоит. Даже системные модули часто запускают сценарии оболочки в фоновом режиме.

Все это, вероятно, не имеет значения для обычного пользователя, но косвенно, что они получают, это в целом более стабильный дистрибутив.

Почему бы не Баш?

Это скорее мнение: лично я бы никогда не выбрал сценарий в тире. Он предлагает только очень простые конструкции. Для большей части программного обеспечения я бы предпочел bash или zsh (или что-то совсем не shell). Какие функции я хотел бы использовать, возможно: расширенные расширения параметров, арифметика оболочки, массивы, возможно, некоторые другие.

Это не должно происходить в сценариях, которые в основном используются для запуска демонов или установки программного обеспечения. Те должны использовать минимальный набор инструкций и держать сценарии удобочитаемыми и простыми. Но это, скорее всего, произойдет, если им станет доступна вся прелесть Баша.

/bin/sh должно быть в основном для запуска внешних программ в достаточно удобной среде, а не для сложных программных систем.

Резюме

/bin/shреализованный dash, обеспечивает совместимый с POSIX быстрый и стабильный язык сценариев, который хорошо работает как стандартный интерпретатор и интерпретатор по умолчанию для сценариев системной оболочки. Эти свойства никогда не будут принесены в жертву в пользу удобных функций.

С точки зрения программиста, он выполняет мантру "делай одно и делай это хорошо".

Это не в первую очередь оптимизация, а разделение обязанностей.

Он уже есть, поэтому нет никаких дополнительных усилий, чтобы его сохранить.

Глядя на это с помощью шляпы конечного пользователя, возникает вопрос: что это за конечный пользователь? Пользователю настольного компьютера наплевать, но он все равно выиграет от более стабильного (и, возможно, чуть более быстрого) распространения. Сопровождающему пакету будет очень важно, и те получат пользу от надежного системного интерпретатора с небольшим, четко определенным и хорошо протестированным набором функций. Программист не должен заботиться, так как они, вероятно, не развиваются в /bin/sh,

PS: двоичный файл bash почти в 10 раз больше двоичного!