Skip to content

NativeString: the pool only on the string path - #1354

Merged
uNetworkingAB merged 1 commit into
uNetworking:masterfrom
nigrosimone:native-string-pool-on-string
Oct 16, 2026
Merged

uNetworkingAB merged 1 commit into
uNetworking:masterfrom
nigrosimone:native-string-pool-on-string

Conversation

@nigrosimone

Copy link
Copy Markdown
Contributor

@ValoChet's idea from #1353: only a string reads the thread-local pool, binary data never does, and pool being set replaces the allocated flag.

A JS handler that passes Buffers (cork, writeStatus, two writeHeader, end), user-space instructions per request on arm64: 9435 to 8990 (-4.7%), the same build twice within 0.1%. With strings it does not move (10580 to 10571).

@github-actions

github-actions Bot commented Oct 8, 2026

Copy link
Copy Markdown

Benchmark: d9d5f78 against 9f90f38

Scenario Base req/s Head req/s Head / base Rounds Noise Busy CPU per request
http/hello-world 116650 115151 0.989x (-1.1%) 0.92 to 0.99 ±13.5% 100% / 100% 8.56 / 8.68 us (1.011x)
http/headers 103793 101238 0.995x (-0.5%) 0.97 to 1.02 ±5.8% 100% / 100% 9.63 / 9.87 us (1.005x)
http/json-post 84161 83296 0.998x (-0.2%) 0.98 to 1.00 ±3.5% 100% / 100% 11.87 / 11.99 us (1.001x)
http/cached 127992 127721 0.998x (-0.2%) 0.99 to 1.00 ±0.8% 100% / 100% 7.81 / 7.83 us (1.002x)
ws/echo-20b 124938 120858 0.992x (-0.8%) 0.94 to 0.99 ±5.7% 100% / 100% 8.00 / 8.27 us (1.008x)
ws/echo-4kb 106096 105841 0.996x (-0.4%) 0.99 to 1.00 ±7.8% 100% / 100% 9.42 / 9.44 us (1.004x)

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.11.1, 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.

@nigrosimone
nigrosimone marked this pull request as ready for review October 8, 2026 11:43
@uNetworkingAB
uNetworkingAB merged commit 139419c into uNetworking:master Oct 16, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants