http: coalesce chunked writes during auto-corking

[GetThatCookie]

This PR is one of four focused changes split out of #64980 following review
feedback.

The full context, rationale, related work, benchmarks, and validation details
are documented there.

The AI-assistance disclosure in #64980 applies to this split PR as well.

[nodejs-github-bot]

Review requested:

• @nodejs/http
• @nodejs/net
• @nodejs/performance
• @nodejs/streams

[pimterry]

I haven't reviewed this in full yet (thanks for breaking up #64980, but this PR is still massive) but I've done a quick skim.

For the chunk writing improvements (independent of corking) I don't think most of this is necessary. There is a big improvement here in combining HTTP chunks within the same tick, which is great, but most of the rest of the code seems to be managing merging low-level calls which we already do internally anyway.

Testing on node without these changes, repeated writes here are already just one writev call:

consthttp=require('http');constnet=require('net');constorigWritev=net.Socket.prototype._writev;net.Socket.prototype._writev=function(chunks,cb){if(this.trackWrites){console.log(`_writev called with ${chunks.length} chunks on socket ${this.remoteAddress}:${this.remotePort}`);}returnorigWritev.call(this,chunks,cb);};constorigWrite=net.Socket.prototype._write;net.Socket.prototype._write=function(data,encoding,cb){if(this.trackWrites){console.log(`_write called with ${data.length} bytes on socket ${this.remoteAddress}:${this.remotePort}`);}returnorigWrite.call(this,data,encoding,cb);};constserver=http.createServer((req,res)=>{req.socket.trackWrites=true;for(leti=0;i<16;i++)res.write('x'.repeat(64));res.end();});server.listen(0,()=>{http.get({port: server.address().port},(res)=>{letbytes=0;res.on('data',(d)=>bytes+=d.length);res.on('end',()=>server.close());});});

Shows a single writev of 16 chunks for the 16 separate res.write calls. We should optimize the chunks, but we don't need to optimize the writev calls - it's already batched anyway.

Can you try simplifying this to combine chunked writes (in terms of transfer-encoding chunks I mean) but without all the writev internal stream changes? I think you'll find you get roughly identical perf boost with 10% of the code changes.

That's separate from the cork fix, I'll look at that closer but it would be helpful to clean this up first so the remaining logic is easier to review.

[GetThatCookie]

Thanks @pimterry you were right. I got a bit overenthusiastic here because there was a lot of room to explore, and I ended up trying to improve too many layers at once.

I now reduced the PR to the HTTP chunk coalescing and corking changes and removed the lower-level stream/writev/vector work. This makes both the invariant and the review surface much clearer.

The vector work was not performance-neutral in isolated measurements; it was typically around 15–20% faster across the configurations I tested. A single writev still leaves some overhead in constructing and processing the individual writes. However, that does not outweigh the additional complexity here. The major end-to-end benefit comes from combining the transfer-encoding chunks, and that can be retained with a fraction of the changes.

PS: Sorry, but I've also realigned the other PRs.

[ronag]

This feels a bit overlay complicated for what it tries to do. Any chance to consider a simpler solution?

[GetThatCookie]

Simplified while retaining the cork/uncork fix and same-tick chunk coalescing - this should be the bare minimum.