[mcollina]

Round 24 of the webstreams performance work. It is stacked on #66702 (the first commit here is that PR's commit); only the second commit, stream: drop rejection step for sync transforms, is new.

Rejection step skipped for non-thenable transform results

transformStreamDefaultControllerPerformTransform chained .then(undefined, rejectionSteps) onto the result of every transform() call, mirroring the reference implementation's promiseCall(transformAlgorithm, ...).then(undefined, ...). When transform() returns a value that is not a thenable (the common transform(chunk, controller) { controller.enqueue(chunk); } shape, and the identity transform), that result cannot reject, so the rejection step can never run. The shared resolved promise is now returned directly, saving a promise and a microtask per chunk. Promise and thenable results keep the rejection step unchanged.

Observable timing

The write promise of such a transform settles one microtask earlier than in the reference implementation. The relative order of every observable stream event is unchanged: a probe of 8 transformer shapes (sync, async, returned promise, thenable, throwing, rejecting, controller.error(), controller.terminate()) at both readable high water marks, logging writes, reads, ready, close and both closed promises, produces the same event sequence on the base and patched builds; only the tick numbers of the sync, error() and terminate() shapes move. This is only observable by counting microtasks.

I also tried returning the user's promise for async transform() (with a non-rethrowing error handler registered first): it measured +0..1.6% because the async function's own promise dominates, so it is not worth the broader timing change.

Verification

• WPT streams, compression and encoding plus the parallel webstream tests (343 files) pass.
• Async context: the existing async-context tests pass, and a differential probe of 40 scenarios (sink write/close/abort succeeding and failing, transformer transform/flush/cancel succeeding, throwing and rejecting, parked writes at both high water marks, error()/terminate(), thenables, pipeThrough with and without an abort signal; sync and async variants) records the AsyncLocalStorage store seen by every user callback and every reaction on the returned promises. The callback → store mapping is identical to the base build in every scenario, and no callback runs outside its context.

Benchmarks

benchmark/compare.js, 20 runs, against the previous commit:

                                                                         confidence improvement accuracy (*)    (**)   (***)
webstreams/lifecycle.js kind='pipe-through' n=50000                             ***     10.40 %       ±5.19%  ±7.00%  ±9.32%
webstreams/pipe-through.js kind='transform' n=500000                            ***      4.57 %       ±1.66%  ±2.23%  ±2.95%
webstreams/pipe-through.js kind='default' n=500000                              ***      4.18 %       ±1.80%  ±2.42%  ±3.21%
webstreams/encoding-streams.js len=16 kind='encode' n=100000                    ***      8.52 %       ±4.54%  ±6.11%  ±8.07%
webstreams/encoding-streams.js len=1024 kind='decode' n=100000                   **      5.57 %       ±3.98%  ±5.33%  ±7.01%
webstreams/encoding-streams.js len=16 kind='decode' n=100000                     **      5.54 %       ±4.10%  ±5.49%  ±7.23%
webstreams/encoding-streams.js len=1024 kind='encode' n=100000                    *      4.48 %       ±3.55%  ±4.77%  ±6.30%
webstreams/creation.js kind='ReadableStreamDefaultReader' n=50000                 *      6.34 %       ±5.95%  ±7.99% ±10.54%
webstreams/creation.js kind='WritableStream' n=50000                              *      4.75 %       ±4.54%  ±6.11%  ±8.07%

The other 10 rows (creation, js_transfer, the remaining lifecycle kinds) are within their confidence intervals. The two creation rows at the 5% level do not touch the changed code and match the expected number of false positives for 19 comparisons.

---

AI Generated, reviewed by me.