Use boolean values for randomUUID benchmark and
deprecate benchmark instead of 0/1.
PR-URL: https://github.com/nodejs/node/pull/60129
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Change createBenchmark to also accept booleans.
PR-URL: https://github.com/nodejs/node/pull/60129
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
PR-URL: https://github.com/nodejs/node/pull/60748
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Jordan Harband <ljharb@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
The original benchmark uses a not very realistic fixture (it has
a huge try-catch block that would throw on the first line and then
export at the end, hardly representative of real-world code).
Also, it measures the entire import including evaluation, not just
parsing. This updates the name to import-cjs to be more accurate,
and use the typescript.js as the fixture which has been reported
to be slow to import, leading users to use require() to work around
the peformance impact. It splits the measurement into two different
types: parsing CJS for the first time (where the overhead of
loading the lexer makes a difference) and parsing CJS after the
lexer has been loaded.
PR-URL: https://github.com/nodejs/node/pull/60663
Refs: https://github.com/nodejs/node/issues/59913
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Instead of measuring the performance of the entire module
initialization, focus only on the import.meta initialization.
PR-URL: https://github.com/nodejs/node/pull/60603
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
This allows us to set up fixtures for the benchmark suite only
once, which can save quite a bit of time when running benchmarks
that require tens of thousands of fixture files or more (e.g.
the module benchmarks).
PR-URL: https://github.com/nodejs/node/pull/60574
Fixes: https://github.com/nodejs/node/issues/58488
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
The previous cpu.sh script was minimal. This change makes it a more
robust and safe utility for managing CPU governors during benchmarks.
The script now includes:
- Checks to ensure it only runs on Linux with root privileges.
- A `reset` command to restore the CPU governor to a dynamically
detected system default.
- A `get` command to check the current governor for all cores.
- An improved usage guide and clearer feedback messages.
PR-URL: https://github.com/nodejs/node/pull/60162
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Also, have it use a null prototype
PR-URL: https://github.com/nodejs/node/pull/60036
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Restore the Buffer.isBuffer() check to avoid unnecessary Buffer.from()
calls when the input is already a Buffer. This improves performance
by 30-50% for buffer-heavy UDP operations.
Includes benchmark test for fixBufferList function to verify the
performance improvements across different data types and chunk sizes.
PR-URL: https://github.com/nodejs/node/pull/59934
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
According to https://github.com/nodejs/performance/issues/186
this benchmark was taking 160 secs for a single run.
Based on a research in a dedicated machine, the results
doesn't have variation based on the configs, so we don't
need to bench all variations.
Signed-off-by: RafaelGSS <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/59587
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
According to recent tests with `calibrate-n` on
a dedicated Hetzner machine (4vCPUs | 16gb) the
results got stable with n=1e5.
The work on https://github.com/nodejs/performance/issues/186#issue-3326002531
has shown this benchmark file spends 2-minutes for a single
run. This should improve things a bit.
PR-URL: https://github.com/nodejs/node/pull/59586
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
There's no need to test all readfile config as
permission model won't impact based on size.
PR-URL: https://github.com/nodejs/node/pull/59589
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
500 + 1000 already cover the curve. 2000 doesn’t add
new qualitative insight — it just extends the same curve
further down (another ~3–4× slowdown).
According to https://github.com/nodejs/performance/issues/186
this benchmark takes one minute to conclude a single run.
This should fix it.
PR-URL: https://github.com/nodejs/node/pull/59588
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
PR-URL: https://github.com/nodejs/node/pull/59459
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
This script should help identify the best N
when creating/updating benchmarks
Signed-off-by: RafaelGSS <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/59186
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: James M Snell <jasnell@gmail.com>
According to https://github.com/nodejs/node/pull/59186 this
benchmark file takes 6 hours to complete a full benchmark/compare.js
script (60 runs in total) and this regression tests unrealitics to do
between Node.js releases. By using calibrate-n scripts I could find
a better N also ajusting some bench configs. e.g: avoid dead code
elimination by V8.
PR-URL: https://github.com/nodejs/node/pull/59187
Refs: https://github.com/nodejs/node/pull/59186
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
punycode has been deprecated and icu.toASCII
method does not exist. This benchmark file
has been failing for a while.
Signed-off-by: RafaelGSS <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/59171
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The variable deadCodeElimination is declared
but not initialized, making it undefined by default.
When using the &&= operator with an undefined left operand,
the result will always remain undefined regardless of
how many iterations run.
```js
let deadCodeElimination;
deadCodeElimination &&= true
deadCodeElimination // undefined
```
PR-URL: https://github.com/nodejs/node/pull/59170
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Edy Silva <edigleyssonsilva@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/58521
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Invalid dates are now handled as equal in all deep comparisons.
PR-URL: https://github.com/nodejs/node/pull/57627
Reviewed-By: Jordan Harband <ljharb@gmail.com>
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
