>> Стоп, а что тот мусорного, не считая неподдерживаемых массивов?
> Вы же сами ответили в предыдущем сообщении. "Зачем хранить все результаты, когда
> нужет только один, последний". Наверное, что бы заполнить 4 (или 8?)
> миллионов байт ОЗУ и измерить время обработки 1000 ошибок страниц (или
> сколько их будет?).

Понятно. В каждом мусоре есть доля мусора))).

>[оверквотинг удален]
>     a = b;
>     b = c;
>     i++;
> }
> Если такое скомпилировать в машинные команды, получится примерно 1 сложение, 2 пересылки,
> 1 декремент (i++ и i <= n эффективнее заменить уменьшением n
> и сравнением с 0) и 1 условный переход. 5 команд и
> 2 зависимости по данным (сложение и 1я пересылка + декремент и
> переход), то есть процессор потенциально может выполнить по 3-2 команды за
> такт.

Это применимо к JS?
Может, на С оно и было, а на JS ещё оверхед на интерпретатор. Если только интерпретатор умеет себя мерять, но я сильно сомневаюсь, что это относится к проекту типа elk-js.
Но и то - на С только при использовании примиттивных неоптимизирующих компиляторов типа tinycc, на gcc и clang без живых измерений не обойтись.