>> Грелка по определению априори горячая. Вопрос в температуре носителя. А ещё бывают
>> электрические грелки. :)))
> Вода в грелке могла остыть, да и забытым на столе бумагам Тузик
> тоже обрадуется.
> Ыххх.... (Двай Нальвай Давадавай)))))))).

А ещё британские учёные скрестили Тузика и грелку. Не прошло и пяти минут, как животное порвало само себя.

>[оверквотинг удален]
>>> 1. Вы меряете время на выполнение всей проги, а не конкретного участка
>>> кода, который может составлять проценты от всего результата.
>> Да, поскольку (допустим) я хочу использовать JS вместо калькулятора. Написал в скрипте,
>> что мне требуется посчитать. Нода считает медленнее, чем интерпретатор из новости
>> (но его надо доработать, что бы скрипт можно было размещать в
>> файле).
> Ну вот - думаю, мало кто сразу понял, что интересует время не
> куска js-кода, а время одиночного запуска движка с этим куском. Другой
> причины, почему включение JIT увеличило время в 10 раз не вижу.
> Сомневаюсь, что это имеет интерес кроме академического.

Как говорили в ФИДО, отучаемся говорить за всех. Почитайте ответы Ordu мне (его вообще стоило бы почитать, что бы не тратить время), он рассматривал такой вариант среди прочих (поиск по слову "unix"). Кроме того, именно в этой ветке я прямо указал задачу https://www.opennet.ru/openforum/vsluhforumID3/125354.html#85

>[оверквотинг удален]
>> отнять от моего первого результата время исполнения пустого скрипта.
>> Результат всякого измерения включат в себя истинное значение и погрешность измерения. Погрешность
>> измерения не определена, потому при вычитании результатов двух измерений погрешности суммируются.
> Эта методика была бы полезна для вашего оригинального кода - меряете время
> для данного куска, затем для пустого кода. И смотрите разницу.
> На счёт мусора - код явно не расчитан на копи-паст - адаптация
> ложится на вас. Так что если он почему-то не годится -
> то только потому что не понял цель измерений. Не похоже, что
> ваши объяснения после старта не достаточно точны. Можно было и по-точнее
> (я выше попытался).

Код с массивом мусорный по той причине, которую Вы сами указали: массив на миллион значений лишний. Кроме того, заполнение массива вносит существенную погрешность.

>>> Кстати: Нельзя ли выполнить прогу по частям - в несколько js_eval() ?
>> Можно. Ещё можно вызывать из JS функции Си.
> Я это спрашивал для одной вещи: пока я, как и другие, думал,
> что цель измерений - время для самой функции фибоначи, прогу можно
> было бы разбить на 3 части - до измеряемого цикла, цикл,
> после цикла. И измерять только сам цикл. Это слегка повысило бы
> точность. Но раз цель другая, то и смысла в этом теперь
> нет.

Аналогичную операцию пришлось бы проделать и с Нодой.

>[оверквотинг удален]
>> Я бы написал "в первом приближении 400 тактов".
> Сразу отвечаю на этот и похожий пост
> 400 тактов было бы для компилированной версии на С (и то, смотря
> чем компилировать). Это машинная команда берёт и выполняется. А в интерпретаторе
> VM - по порядку:
> - разбор команды (strlen, strcmp, strtok,...) = выбор операции с установкой её
> параметров,
> - переход по адресу операции (допускаю, что использутся switch).
> - операция
> - на следующую строку

Вот ещё один мой похожий пост https://www.opennet.ru/openforum/vsluhforumID3/125354.html#211
который я написал ранее и указал там, что в первом приближении интерпретатор на порядок медленнее. Прикиньте все эти strcmp(), как раз оно и выйдет.

Впрочем, это не меняет сути. Кто может привести хоть какие-то цифры, тот их приводит (вообще-то они нужны, что бы _проверить_ результаты измерений). Кто не знает откуда они берутся - тот написал "стремится к 0". Кстати, strlen() очевидно лишняя.

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

Ещё возможно посмотреть сорцы, или хотя бы описание почитать.