-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start time performance regression when upgrading from 16.x to 18.x #45662
Comments
According to my local benchmarks, Node 18 is 12.24% slower in start time than Node 16.
|
Any idea why its slower? Perhaps @joyeecheung might have more insight here. |
cc @nodejs/performance |
Here's the most recent benchmarks I ran after the recent startup performance pull request got merged today:
|
Sorry that I missed the ping. #45716 and #45659 should fix the baseline startup regression (if not faster, I got locally a slight performance boost when I compared it against v14 and v16, which probably came from snapshotting internals), and I have another WIP to make it 2-3% faster. The regression in most-builtins-loaded startup is expected because the builtins simply has bloated more since previous releases (even if the same set of builtins are required, they actually have more sub-namespaces now for new alternatives). But then most users probably don’t have to load every builtin out there in Node.js during startup. |
Thanks @joyeecheung 🙏 Just checking in here now (happy new year 🎉 ) It looks like both #45716 and #45659 have been merged but we still need to backport both. Would you like me to create the PRs to backport those into |
I found this issue searching for Node.js v18 vs Node.js v16 performance. I performed an upgrade on some Linux based projects yesterday from 16.19.0 to 18.13.0 and I noticed slightly longer runtimes. Small projects but increases on the order of one or more seconds to accomplish the same task in 16.19.0. Mostly CPU bound tasks performing graphing using Chart.js, node-canvas and ffmpeg. Glad to see I am not the only one who noticed something a bit off. I am going to downgrade back to 16.19.0, as I have the Node upgrade process worked out to be trivial with the necessary "npm rebuild" operations, and see what changes. |
Facing the same slowdown in upgrading from node 12 to node 19 |
@muhammadbilal87 Which version of Node.js 19? From my testing Node.js 19.x with the recent patches is as fast as or faster than releases up to v14.x (I didn't test further beyond that). If the issue is still present in Node.js 19.x, I wonder if that's an issue from something else, for example |
In our CI/CD and server we are using node:19-alpine and on on our local we
are using 19.3.0
…On Fri, Mar 3, 2023, 7:40 PM Joyee Cheung ***@***.***> wrote:
@muhammadbilal87 <https://github.com/muhammadbilal87> Which version of
Node.js 19? From my testing Node.js 19.x with the recent patches is as fast
as or faster than releases up to v14.x (I didn't test further beyond that).
If the issue is still present in Node.js 19.x, I wonder if that's an issue
from something else, for example npm run can be 10x slower than the
Node.js core startup.
—
Reply to this email directly, view it on GitHub
<#45662 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALKR2ZFCYMW4QGHOGY3JKRDW2H7FTANCNFSM6AAAAAASNUUWV4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I think that might be a different issue, possibly related to other components in Node.js being slower (or maybe user code too if they have version-detect code) - do you have a smaller repro? Or is something like |
It appears #45716 has been backported and is available in NodeJS v18.13.0. Benchmarks from Linux (Docker using WSL2) compiled from source with
There does appear to be a separate performance regression which in one service has slowdown down response rates by ~30% (under investigation), which might explain why startup performance regressions are still being reported (that is, it's not a startup performance regression but rather affecting effecting performance in general). Benchmarking across versions with |
Thanks for confirming that the fix worked. I think we can close this now. Please feel free to open separate issues for other regressions. |
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them. This helps preventing regressions like the one reported in nodejs#45662.
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them. This helps preventing regressions like the one reported in nodejs#45662.
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in nodejs#45662.
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in nodejs#45662.
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in #45662. PR-URL: #50708 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in #45662. PR-URL: #50708 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in nodejs#45662. PR-URL: nodejs#50708 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in nodejs#45662. PR-URL: nodejs#50708 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in #45662. PR-URL: #50708 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in #45662. PR-URL: #50708 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in #45662. PR-URL: #50708 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Divide builtins into two lists depending on whether they are loaded before pre-execution or at run time, and give clearer suggestions about how to deal with them based on the category they are in. This helps preventing regressions like the one reported in #45662. PR-URL: #50708 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Richard Lau <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
Version
v18.12.1
Platform
Subsystem
No response
What steps will reproduce the bug?
Run the following script replacing
node -p '7+8'
with the node binary and any command you want to benchmark.I chose
7+8
as a simple addition example but it reproduces with anything.Run once with node 16.x and then run again with node 18.x binary.
How often does it reproduce? Is there a required condition?
Every time
What is the expected behavior?
Expected Node.js 18 to perform the same as Node.js 16
What do you see instead?
Node.js 16 was faster and Node.js 18 was slower
16.x
18.x
That's a decrease of 10%
Additional information
This regression affects macOS, Linux, etc
The text was updated successfully, but these errors were encountered: