> Собери себе новый zsh.

Посмотрю, токо сомневаюся шо он быстрее ash. :)
>надо иметь в виду, что она всегда уступает скриптам в том, что её в случае чего невозможно модифицировать.

По этому я и есть фанат shell. :)
>в данном случае при использовании любого интерпретатора, затраты в цикле будут мизерны.

Не забывай шо read -t 0 это костыль, а не спец. команда, в быстром цыкле разница все равно будет.
Я б создателям утилит посоветовал команде yes добавить ключ задания пауз между каждой строчкой, может не такой бесполезной будет; если б это было просто.
>Стоп. Busybox тут прозвучал довольно неожиданно, но хочу заметить, что там вообще-то не usleep, а busybox usleep вызывается. А если ты вызываешь usleep, так это оттого лишь, что usleep -- это ссылка на busybox.

Неужели есть разница отдельный бинарник или из под busybox? Да я знаю о симлинках, сам же их ставил в моде.
>Это процесс довольно-таки быстрый

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

Я извиняюся, ошыбся ноликом, реч о цыкле с usleep 10000, то есть 100 раз в секунду.
И на 133 МГц +55% в цыкле с usleep перед цыклом с нативным генератором пауз с тем же временем.
Интересно шо простое зацыкливание usleep дает уже +25%, то есть usleep не токо сам по себе обжора, но и тормозит видимо другие задачи. По крайней мере на моем ЦП i.MX31
>Может у тебя busybox был неправильный какой, может ядро древнее, собранное на коленке неизвестно кем неизвестно как...

# uname -a
Linux (none) 2.6.10_dev  armv6l unknown
# busybox
BusyBox v1.01 (---) multi-call binary

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