Repository navigation
Conversation
The asynchronous convenience methods (`zlib.deflate()`,
`zlib.inflate()`, `zlib.gunzip()`, ...) wrote the input to a
Transform stream and then ended it. That took two threadpool round
trips, one for the data and one for the final flush, and ran the
result through the stream machinery.
The whole input is known up front, so unless `info` or a custom
`flush` is requested, process it with the finish flush directly, the
way the synchronous methods already do, and collect the output in the
write callback. A call whose output fits in one buffer now takes a
single threadpool round trip. The output is unchanged: the previous
two-write sequence already produced the same bytes as the synchronous
methods. `zstdCompress()` keeps the separate end-of-frame write,
because a single `ZSTD_e_end` call can produce slightly larger frames.
benchmark/compare.js, 40 runs, n=100000:
confidence improvement
zlib/inflate.js method='inflate' *** +94.91 %
zlib/deflate.js method='deflate' *** +66.27 %
Signed-off-by: Yagiz Nizipli <yagiz@nizipli.com>
Assisted-by: Grok
nodejs-github-bot
added
needs-ci
anonrig
added
the
semver-minor
This was referenced Oct 19, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #66854 +/- ##
=======================================
Coverage 90.50% 90.50%
=======================================
Files 797 797
Lines 278195 278240 +45
Branches 53453 53460 +7
=======================================
+ Hits 251777 251832 +55
+ Misses 16795 16786 -9
+ Partials 9623 9622 -1
🚀 New features to boost your workflow:
|
mcollina
reviewed
Oct 20, 2026
mcollina
left a comment
mcollina
left a comment
Member
There was a problem hiding this comment.
change is good. Are the tests actually needed given it’s an optimization?
Member
Author
It doesn't hurt to cover this edge case. @mcollina |
mcollina
added
the
request-ci
github-actions
Bot
removed
the
request-ci
Collaborator
anonrig
added
the
commit-queue
nodejs-github-bot
added
commit-queue-failed
Collaborator
Commit Queue failedThe pull request was removed from the Commit Queue and labeled
commit-queue-failed
Full Commit Queue output |
Member
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The async convenience methods (
zlib.deflate(),zlib.inflate(),zlib.gunzip(), ...) write the input to a Transform and then end it. That's two threadpool round trips per call, one for the data and one for the final flush, plus the stream machinery on top. In a CPU profile ofbenchmark/zlib/inflate.js method=inflate, the main thread sits idle about 71% of the time waiting on the threadpool.We already have the whole input up front, so this hands it to the handle in a single write with the finish flush, the same way the
*Syncmethods do, and collects the output in the write callback. A call whose output fits in one buffer now takes one round trip. The work still runs on the threadpool.These stay on the stream path:
info: true, since the engine is handed back to the caller.flush, which can change the output bytes.zstdCompress(). A singleZSTD_e_endwrite makes frames 3–18 bytes larger thanZSTD_e_continuefollowed byZSTD_e_end, so I left it alone.The output doesn't change. For deflate, gzip, raw deflate and brotli, the old two-write sequence already produced the same bytes as the sync methods. I compared all the async methods plus
gzipSync()/deflateSync()on four inputs (source text, text plus random bytes, a short string, empty) against a build of the base commit: 28/28 outputs are byte-identical, and each build decompresses the other's output.There are two observable differences. The success callback now runs straight from the write completion, so async_hooks sees it in the
ZLIBresource instead of aTickObject, which is how fs callbacks behave too.AsyncLocalStoragecontext is unchanged, and the new test checks it. Errors still arrive through the'error'event like before. Also,thisinside a non-arrow callback is still the internal engine, but it's never ended now, sowritableEnded,writableFinishedandreadableEndedarefalse(it's still destroyed, withbytesWrittenset), andinfo: true, the documented way to get the engine, keeps the old stream path.Two new tests:
test-zlib-convenience-async.jscovers the contract: every input type, interop with the sync methods, invalid and truncated input,maxOutputLength,info,rejectGarbageAfterEnd, dictionaries,finishFlush, and that the callback never runs synchronously. It passes on the base commit too.test-zlib-convenience-async-round-trip.jsuses async_hooks to check that a small call takes exactly one round trip. It fails on the base commit, which takes two.Benchmarks
benchmark/compare.js, 40 runs,n=100000, against a build of the base commit with the same configure flags. The defaultmethod/inputLenare kept and onlynis scaled down.inflate.js method='inflate'deflate.js method='deflate'--max-regression 5overdeflate.js,inflate.js,pipe.jsandcreation.js(20 runs) passes. The sync methods,createDeflatewrites, pipes and stream creation all stay within about 2%.compare.js, run 2 (40 runs)
compare.js --max-regression 5 (20 runs)
Below, Chrome talks to two local servers, one on the base build and one on this PR. It decodes
zlib.gzip()/zlib.deflate()/zlib.brotliCompress()responses, and sendsCompressionStreamuploads that the servers decode withzlib.gunzip()/zlib.inflate(). The payloads match on both, the round trip count drops from 2 to 1, and sequentialzlib.inflate()calls get faster.