You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current node:fs benchmarks take 10+ hours on our CI, making it impossible to run all of them and have a healthy emotional state. It also blocks other benchmark jobs.
I recommend aiming for 2-3 hours and changing the benchmarks according to fit into this deadline.
I think the fs benchmarks are having the same kind of issue that happen to many other benchmarks - they have a bit too many combinations of the parameters, and some of them are unnecessary. For example there are usually too many size / len variations. For example in this.
We probably just need 2-3 combinations by default. Or at least only pick 2-3 combinations when we are running the entire fs benchmark. There could be something OS-specific about them to make certain options not representative enough to be in that default set but I think we can always expand the variations when there's actually any doubt.
I think the fs benchmarks are having the same kind of issue that happen to many other benchmarks - they have a bit too many combinations of the parameters, and some of them are unnecessary.
We could also make benchmark iterations scalable. Running a few benchmarks for 1e5 iterations is usually not a problem, but running all benchmarks for 1e5 iterations might be.
I usually start with 1e7 iterations, and if it takes more time than I can bear, I reduce it by a factor of 10 and check if the benched result is not significantly different. Rinse and repeat.
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Activity
joyeecheung commentedon Sep 17, 2023
I think the fs benchmarks are having the same kind of issue that happen to many other benchmarks - they have a bit too many combinations of the parameters, and some of them are unnecessary. For example there are usually too many
size/lenvariations. For example in this.node/benchmark/fs/readfile-promises.js
Lines 17 to 24 in cdcb01a
We probably just need 2-3 combinations by default. Or at least only pick 2-3 combinations when we are running the entire fs benchmark. There could be something OS-specific about them to make certain options not representative enough to be in that default set but I think we can always expand the variations when there's actually any doubt.
mscdex commentedon Sep 18, 2023
This would probably be solved by #39285
RafaelGSS commentedon Sep 18, 2023
Also related nodejs/build#3483.
tniessen commentedon Sep 18, 2023
We could also make benchmark iterations scalable. Running a few benchmarks for 1e5 iterations is usually not a problem, but running all benchmarks for 1e5 iterations might be.
Uzlopak commentedon Sep 19, 2023
I usually start with 1e7 iterations, and if it takes more time than I can bear, I reduce it by a factor of 10 and check if the benched result is not significantly different. Rinse and repeat.
H4ad commentedon Sep 28, 2023
Is possible to create some kind of repo/issue to track slow benchmarks? Like we have for flaky tests?
github-actions commentedon May 28, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jun 28, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.