-
ran some benchmarks with nvm and it does appear there is correlation with each new node version and decreasing performance of uWS.js http (requests per second) |
Beta Was this translation helpful? Give feedback.
Replies: 14 comments 14 replies
-
Absolutely. That's what I've been saying for years. The only limit uWS.js has is They never benchmark their changes and when they do, they still allow small drops in perf. by every release, because they have no discipline or leadership to refuse offending commits. Many drops make an ocean over time. |
Beta Was this translation helpful? Give feedback.
-
Websocket echos per second also showing the same thing. What is going on over there they just keep adding more code and it is slowing stuff down? |
Beta Was this translation helpful? Give feedback.
-
Must be something they can do to fix it, that's a 25% performance drop for sockets and 20% drop for http from node v10 and this library only hooks into theirs minimally so maybe have someone over there look into it, get it back up to 100% |
Beta Was this translation helpful? Give feedback.
-
If you look at the history of (C++) uWS you see that the trend went the other way: v0.14.8: v18.9.0: This is for WebSockets but the same can be seen in Http, even though v18 has a complete router on top. We've remained at a flat line since the jump from v0.14.8 -> v0.15.0, because we do not allow small drops to slowly form an ocean over time. If someone sends a PR that decrements perf. I refuse it. |
Beta Was this translation helpful? Give feedback.
-
I wrote a benchmark that just does
And this benchmark does nothing at all besides calling If you then look at the vanilla (Google) V8 counterpart we get 104ms in Node.js 8, and 136ms in Node.js 14.5.0. So anything above 200ms is definitely a regression caused by Node.js itself, and not V8 or any native addon. |
Beta Was this translation helpful? Give feedback.
-
@BridgeAR You had some questions regrading this a while back - what's your take on this? |
Beta Was this translation helpful? Give feedback.
-
For the visual learners |
Beta Was this translation helpful? Give feedback.
-
Alright, nothing we can do here. |
Beta Was this translation helpful? Give feedback.
-
Apparently @trevnorris stopped working on nodejs core 3 years ago, and I guess @addaleax took over responsibility for those parts. This maps well with the graph; a slow but sure decline in perf. with every release |
Beta Was this translation helpful? Give feedback.
-
I did manage to reach Trevor Norris on this and he's made a very detail per-commit benchmark and found the most offensive commit in this. That's great but unfortunately Trevor is not working on Node.js anymore, so I don't know if people will listen to him on this. https://gist.github.com/trevnorris/35c8e570c3097f58739b84bfa3f0a390 |
Beta Was this translation helpful? Give feedback.
-
This is the most offending commit: nodejs/node#30959 It's ironic that they claim to have run benchmarks when they clearly did not! |
Beta Was this translation helpful? Give feedback.
-
Trevor stats for |
Beta Was this translation helpful? Give feedback.
-
@hst-m Is this still a problem in node v17? If that's still the case then why shouldn't we create an issue on nodejs repo? |
Beta Was this translation helpful? Give feedback.
-
I ran benchmarks back to Node 14, I see 18% improvement since this issue was created, and the commit at 17.4 helped. The lowest point was Node 14.5, and the latest Node 17.4 is the fastest since Node 12. It's about half way back to the Node 10 high. So it's good to see a positive direction |
Beta Was this translation helpful? Give feedback.
Absolutely. That's what I've been saying for years. The only limit uWS.js has is
node::MakeCallback
and they manage to tamper with that every release, to our disadvantage.They never benchmark their changes and when they do, they still allow small drops in perf. by every release, because they have no discipline or leadership to refuse offending commits. Many drops make an ocean over time.