Repository navigation
Conversation
Benchmark:
|
| Scenario | Base req/s | Head req/s | Head / base | Rounds | Noise | Busy | CPU per request |
|---|---|---|---|---|---|---|---|
| http/hello-world | 114932 | 115522 | 1.006x (+0.6%) | 1.00 to 1.01 | ±0.9% | 100% / 100% | 8.69 / 8.65 us (0.994x) |
| http/headers | 98435 | 99406 | 1.008x (+0.8%) | 1.01 to 1.02 | ±3.3% | 100% / 100% | 10.15 / 10.05 us (0.992x) |
| http/json-post | 85537 | 85510 | 1.000x (-0.0%) | 1.00 to 1.00 | ±2.3% | 100% / 100% | 11.68 / 11.68 us (1.000x) |
| http/cached | 129159 | 129136 | 1.001x (+0.1%) | 1.00 to 1.00 | ±0.9% | 100% / 100% | 7.74 / 7.74 us (0.999x) |
| ws/echo-20b | 117860 | 118117 | 1.002x (+0.2%) | 1.00 to 1.01 | ±1.4% | 100% / 100% | 8.48 / 8.45 us (0.998x) |
| ws/echo-4kb | 102518 | 102393 | 1.000x (-0.0%) | 1.00 to 1.00 | ±3.4% | 100% / 100% | 9.74 / 9.76 us (1.000x) |
4 rounds of 3s per scenario, each round loading base, head and a second process of each one, from a copy of its build, after the other, in an order that changes every round. "Head / base" is the median of the per-round ratios of req/s and "Rounds" their range. "Noise" is how far base/base and head/head, the same code on both sides, got from 1 in this same run: that is what the machine did, so a row is marked only when the median moved further than that, at least 2%, and every round moved the same way: 👀 slower, 🏆 faster. "Busy" is the cpu time of the server process over the round and "CPU per request" that time divided by the requests it answered, with the head/base ratio judged against its own same-code band and bold when it cleared it. When busy is well under 100% the load generator set the pace, the req/s are its and the cpu per request is the column to read. Only the ratios are comparable across runs, the absolute figures depend on the runner.
Node v26.10.0, AMD EPYC 7763 64-Core Processor, 4 cores (server on cpu 0, load on 2,3), http_load_test and load_test with 100 connections.
|
Doesn't seem to be a speed up.
Den ons 30 sep. 2026 22:54github-actions[bot] ***@***.***>
skrev:
… *github-actions[bot]* left a comment (uNetworking/uWebSockets.js#1340)
<#1340 (comment)>
Benchmark: 8e79e91 against f4fc521
Scenario Base req/s Head req/s Head / base Rounds Noise Busy CPU per
request
http/hello-world 114932 115522 1.006x (+0.6%) 1.00 to 1.01 ±0.9% 100% /
100% 8.69 / 8.65 us (0.994x)
http/headers 98435 99406 1.008x (+0.8%) 1.01 to 1.02 ±3.3% 100% / 100% 10.15
/ 10.05 us (0.992x)
http/json-post 85537 85510 1.000x (-0.0%) 1.00 to 1.00 ±2.3% 100% / 100% 11.68
/ 11.68 us (1.000x)
http/cached 129159 129136 1.001x (+0.1%) 1.00 to 1.00 ±0.9% 100% / 100% 7.74
/ 7.74 us (0.999x)
ws/echo-20b 117860 118117 1.002x (+0.2%) 1.00 to 1.01 ±1.4% 100% / 100% 8.48
/ 8.45 us (0.998x)
ws/echo-4kb 102518 102393 1.000x (-0.0%) 1.00 to 1.00 ±3.4% 100% / 100% 9.74
/ 9.76 us (1.000x)
4 rounds of 3s per scenario, each round loading base, head and a second
process of each one, from a copy of its build, after the other, in an order
that changes every round. "Head / base" is the median of the per-round
ratios of req/s and "Rounds" their range. "Noise" is how far base/base and
head/head, the same code on both sides, got from 1 in this same run: that
is what the machine did, so a row is marked only when the median moved
further than that, at least 2%, and every round moved the same way: 👀
slower, 🏆 faster. "Busy" is the cpu time of the server process over the
round and "CPU per request" that time divided by the requests it answered,
with the head/base ratio judged against its own same-code band and bold
when it cleared it. When busy is well under 100% the load generator set the
pace, the req/s are its and the cpu per request is the column to read. Only
the ratios are comparable across runs, the absolute figures depend on the
runner.
Node v26.10.0, AMD EPYC 7763 64-Core Processor, 4 cores (server on cpu 0,
load on 2,3), http_load_test and load_test with 100 connections.
—
Reply to this email directly, view it on GitHub
<#1340?email_source=notifications&email_token=A2NMOML3E4QURAADVZRG5BL5RVXHXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJRHE2TINJRG42KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5919545174>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2NMOMJRJEUB5AXXYRUFXH35RVXHXAVCNFSNUABFKJSXA33TNF2G64TZHMYTIMRWGMYTCOJRHNEXG43VMU5TKNRVGI3TGMBVGUYKC5QC>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/A2NMOMJ2UXFTS2NRQ456UDD5RVXHXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJRHE2TINJRG42KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ>
and Android
<https://github.com/notifications/mobile/android/A2NMOMO64NW33SVXXQMWG4D5RVXHXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJRHE2TINJRG42KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>.
Download it today!
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Turns out my benchmark was flawed and there's no actual benefit here. Closing this PR, don't mind me! |
|
Regardless I will probably have an agent change all ReturnValue.Set to use those POD variants. |
This PR optimizes the WebSocket::send V8 wrapper function and modernizes its code.
These changes may also be applied to other V8 bindings to help enhance performance and modernize the code base.
C++20 [[unlikely]] gives a little performance and stability gain, but not that much.
The real benefit comes from removing
Integer::NewFromUnsigned(isolate)of the return path.args.GetReturnValue().Set()can be fed directly with some native valuebool, int32_t, uint32_t, double, Local<v8::Value>.Preventing the creation of a temporary value and lowering garbage collector work.
Test case using a simple ws.send("Hello World!");
My results show a 6% performance gain with average time lowered from 977 ns to 911 ns.
It also shows a stability increase with the maximum time spike cut down from 7.41 µs to 1.06 µs
I am not 100% sure about my test case, so if someone could try and validate the result, it would be appreciated.