>> Собери себе новый zsh.
> Посмотрю, токо сомневаюся шо он быстрее ash. :)

Ну я бы не вдавался в крайности. ash/dash как posix shell-ы конечно самые быстрые, но и не умеют ничего (потому что posix shell-ы); bash исторически самый распространённый, но при этом тормозилка та ещё, плюс дебаг на нём сложный. Zsh же -- вариант промежуточный. Многое может, но на порядок шустрее bash-а. Попробуй, может тебя устроит.

> Я б создателям утилит посоветовал команде yes добавить ключ задания пауз между
> каждой строчкой, может не такой бесполезной будет; если б это было
> просто.

Вообще-то философия GNU предполагает, что ты не будешь изменять старую утилиту, а вместо этого напишешь новую. Что, кстати, идея. Почему мы не можем просто-напросто написать новую утилиту и добавить её в coreutils? Тем более, что у тебя код zinterval уже на руках есть.

>>вызов в скрипте usleep 100000, приводящий к обращению в busybox 10 раз в секунду, пожирал 50% процессорного времени?
>>Слушай... Не верю. Не должно такого быть. Надо смотреть на твою систему и анализировать.
> Я извиняюся, ошыбся ноликом, реч о цыкле с usleep 10000, то есть 100 раз в секунду.

Всё равно не верю. Позволь поясню:

% /usr/bin/time -p dash -c "while true; do busybox usleep 10000; done"
real 179.48
user 0.16
sys 1.28

За 3 минуты реального времени -- менее полутора секунд процессорного времени потрачено.

>>Может у тебя busybox был неправильный какой, может ядро древнее, собранное на коленке неизвестно кем неизвестно как...
> # uname -a
> Linux (none) 2.6.10_dev  armv6l unknown
> # busybox
> BusyBox v1.01 (---) multi-call binary

Возможно, дело вот в этих вот самых древностях.

> Кажется мелочью эти все задержки, но потом это всё растет (речь о
> програмировании в общем) и програма когда то работавшая на 0,5 ГГц
> уже задыхается на 4 ГГц в новых версиях...

Утилиты ис ОС GNU стабильны, как часы: они получают только багфиксы и изредка оптимизации.