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

> For example, we need to test in a ready-plus-read() scenario instead of simple sync read(). 

The sync test in the benchmark already does an async action.  It does effectively:

```
sync read
sync read
...
sync read
async resolve
```

I highly doubt moving the async resolve before the sync reads will materially impact the results.

> And I want to see something more realistic, like the scenario you outline, where we do I/O for a message and then split it into several objects. And we need to eliminate these scheduler artifacts.

This is difficult to benchmark when you also claim the reference implementation is unoptimized.  Open to suggestions here (or benchmark code!).

> Also, I don't see why you want sync read + state + ready over readBatch; I didn't see you address this point.

I have a number of reasons for favoring a read+state+ready solution in `.getReader()` over an additive solution:

* Sync read+state+ready is more primitive.  Async read can be built on top of it easily, but not the other way around.
* If we believe performance is a problem with async read (which I do) then making it the default is a footgun.
* I think we will see people recommending that everyone always use the additive API to avoid the footgun.  This is fine, but it suggests to me it should just be the default then.

In terms of possible additive APIs, I think I prefer something other than readBatch() now.  Requiring code to always deal with a possible returned array (or single value) is just a bad API and I don't want to require it to achieve performance.

If additive is the only possible route, I think I might prefer a `stream.getSyncReader()` that provides a read+state+ready.

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