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

Ok, I have a semi-working benchmark:

  https://github.com/wanderview/streams-time-echo

It basically works by streaming an series of timestamps from a node.js server.  The browser receives these with a fetch Response stream, parses the timestamps out into individual "objects", and then passes these on via either an asyncRead() or syncRead().  Every time we get a chunk of data from the server we end up with many timestamp objects to pass on, so it should test the "populated pipe" concept I was worried about above.

I say "semi" because it locks up now and then.  I believe this is due to a combination of trying to do my own back pressure with the buffering of data in the chrome body stream or maybe the node http lib.  (Unfortunately the chrome fetch body stream does not do back pressure itself yet.)

In any case, it works well enough that I got some reasonable looking data.  See the "macro benchmark" tab:

  https://docs.google.com/spreadsheets/d/1rl6mbD2z1x1bgJLD6y9KJLYWjppB7BujfiWvUMjYTVs/edit?usp=sharing

Summary of results:

* Desktop shows no difference between async and sync read paths.
* Nexus5 with native promises shows a statistical difference between async read and sync read.
* Nexus5 with bluebird promises shows no difference between async and sync read.

The only other good benchmark I can think of is a very "wide" server that has to handle numerous simultaneous streams.  This is basically the node.js use case.  It doesn't seem very applicable to js running in the browser, though.  Unfortunately I don't have time to investigate this particular use case.

At this point I'm inclined to accept the async promise-returning read().  It seems reasonable that native promises can achieve the same performance as bluebird in the long term.

Thoughts?

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