This change improves the 100MB Write benchmark from ~9s to ~7s.
Bumping `highWaterMark` to >1 also changes the stream's interaction with `AbortController`, so now the chunk processed during an abort is included in the write.
I believe this behavior has to do with the task queue order of the callback for the `AbortSignal`'s `abort` event - so now with multiple chunks in the queue, the last chunk is written before the `abort` event is processed. I was unable to force this writing code to occur after the `abort` event in a deterministic way.
This situation is a rare edge case so letting it through.
Header A\r
abc\r
def\r
+abort\r
// ## Example 1.7: Abort a transformation
//
// Pass an [`AbortSignal`](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) to `.pipeTo()` to gracefully
-// abort a transformation. All transformations enqueued up until the row causing the abort (but *not* including the abort
-// row itself) will be saved to disk.
+// abort a transformation. All transformations enqueued up until the row causing the abort (including the abort row
+// itself) will be saved to disk.
//
// Aborting throws an error, so you must also add a `.catch()` to handle the abort.
async abort() {
await this.close();
}
- });
+ }, new CountQueuingStrategy({ highWaterMark: 4 })); // "4" picked based on manual benchmarks
this.#status = status;
}