Там конкретны, рассчитывает на скорость удара по сравнению с тире?

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

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

Это просто ветвления 10 000 подоболочек один за другим. Теперь выполните его с ударом и с тире и время им:

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

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

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

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

Скорость Shell во времена systemd

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

Так как я не вовлечен в политику Ubuntu, я попытаюсь дать ответ, как это появляется мне:

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

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

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

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

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

Почему бы не колотить?

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

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

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

Сводка

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

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

Это не, прежде всего, оптимизация, но разделение обязанностей.

Это уже там, таким образом, это не дополнительное усилие сохранить его.

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

PS: двоичный файл удара является почти 10 раз размером двоичного файла тире!