Re: [streams] rsReader.readBatch(numberOfChunks)? rbsReader.read(view, { waitUntilDone: true })? (#320)

Thanks for the investigation in benchmarks. They're tricky indeed, and I don't feel that we've really got anything rigorous yet. But at least we have some idea of the range.

I'm not opposed to adding a readBatch(). It has some nice symmetry with writev or similar (#27). However, sync read() is not very sensible at this point. To use it you need to have an async wait-for-readable that you normally use. You might as well fold the async wait-for-readable plus sync read-until-empty into a single async readBatch().

> I feel very strongly that we should not pessimize the common case to accommodate the aesthetics of the ByobReader optimization.

And I feel equally strongly that you are misrepresenting "the common case." You've found very specific scenarios where this will matter. In particular:

- The consumer (e.g. writable stream) must be slower than the reader, so as to cause backpressure to accumulate chunks in the buffer
- There must be no I/O involved at any point in the chain---the data must be entirely generated in memory---otherwise the I/O cost would dwarf the read() costs, as we saw with just a simple setTimeout(,0).
- The person who's generating all this data in memory must not respect the backpressure signals from the readable stream telling it that its queue is full.
- The person who's generating all this data in memory has decided to use a readable stream, instead of simply using, say, an array, to represent a bunch of data being held in memory. (Which might be advantageous sometimes, I agree---just like `Promise.resolve(5)` is sometimes more useful than `5`.)
- The consumer is concerned about time spent on read operations, but is not concerned about time spent on GC or concerned with memory consumption. (If they were, they would be using BYOB.)

I think this set of circumstances is extremely rare. My instinct when faced with this kind of scenario is to not include readBatch, or to include it as experimental in implementations behind a flag, and then wait for true real-world streaming programs to appear which we can use to test: does readBatch actually make a difference?

It may be that these circumstances do all come together with enough frequency to advocate for API addition. However, I don't think we can know that without seeing some serious stream deployment in the wild, and I certainly don't think we can call this confluence of circumstances "the common case."

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/320#issuecomment-91424200