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

So I agree that promises are probably not the end of the world in these two scenarios:

* stream pipeline throttled by source I/O
* stream pipeline throttled by sink I/O

But I don't think that describes every scenario.  Its quite conceivable to envision stream sources and sinks that are completely memory driven.  Should pipelines based on these types by pessimized?

The classic example here is where you write data to a pipe.  The chunks go into a memory buffer until its "full" causing back pressure on the source.  I/O occurred when populating the pipe, but reading from the pipe may have a many chunks available without any I/O.

In these conditions I think the requirement that every read() is a separate Promise is quite expensive.  The cost here is mainly the object creation and the required async microtask schedule.

In IRC @domenic asked for citation that the promise approach was "much slower" than a sync read in these cases.  So I wrote a small test to simulate reading from a pipe or memory source:

  https://github.com/wanderview/streams-promise-read

You can execute the test by visiting this page and looking at your js console:

  https://blog.wanderview.com/streams-promise-read/bluebird.html

Here are some cleaned up results from firefox nightly running on my beefy MBP.

```
   10 chunks in pipe: sync-read: 18.8 us/chunk vs. promise-read: 625.4 us/chunk
  100 chunks in pipe: sync-read:  0.3 us/chunk vs. promise-read:  20.5 us/chunk
 1000 chunks in pipe: sync-read:  0.2 us/chunk vs. promise-read:  28.1 us/chunk
10000 chunks in pipe: sync-read: 0.03 us/chunk vs. promise-read:   7.4 us/chunk
```

The real kicker here for me is it takes over 6ms just to drain a pipe with 10 chunks.  That's a very realistic workload for pipes and huge amount of time considering what its doing.

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