У меня есть большой JS файл, который генерируется процессом сборки. Я заметил, что после внесения изменений запуск в первый раз занимает гораздо больше времени, а затем последующие выполнения выполняются быстрее:
$ node --version
v12.5.0
$ time node build/jsx/my_script.js
real 0m4.188s
user 0m0.144s
sys 0m0.417s
$ time node build/jsx/my_script.js
real 0m0.602s
user 0m0.141s
sys 0m0.404s
$ time node build/jsx/my_script.js
real 0m0.569s
user 0m0.145s
sys 0m0.369s
Более 4 секунд для первого запуска, но затем около половины секунды. для последующих запусков. Даже если я покидаю терминал и некоторое время выполняю другую работу, повторный запуск сценария остается быстрым, пока его исходный код не будет восстановлен. Поэтому я не думаю, что это просто обычный c кэш операционной системы.
Я знаю, что другие языки сценариев могут кэшировать внутреннее представление сценария для ускорения последующих запусков, например Python имеет свои *.pyc файлы . Однако я не знал, что node.js сделал что-то подобное. Это, конечно, не оставляет очевидных файлов кэша, которые я заметил.
Большинство ответов на Хранит ли nodejs / V8 скомпилированный машинный код где-нибудь на диске? устарели, и принятый в настоящее время только показывает параметр --print-bytecode без ответа, где или если node.js хранит байт-код между запусками. Конечно, похоже, что node.js может использовать какой-то кеш байт-кода (например, https://github.com/nodejs/node/issues/11842), но неясно, действительно ли .
Как node.js может запустить мой скрипт намного быстрее после одного более медленного выполнения? Есть ли способ «разогреть» механизм без фактического запуска скрипта? Есть ли способ «обойти» механизм тестирования производительности в худшем случае?