Re: [whatwg/streams] ReadableStream.from(asyncIterable) (#1083)

I think the optimization is even trickier :(. Checking using V8's `IsArray()` doesn't guarantee that the optimization is nonobservable, because someone could have messed with `Array.prototype` to insert a getter for `0`, or override the getter for `[Symbol.iterator]`, or something like that. I suspect V8 has ways of detecting such problems so that they can deopt arrays generally, but I doubt they're part of the public API, and they're probably intertwined with the VM pipeline instead of something that could be easily exposed.

Having actual data is great. I'm unsure how to interpret the results... I mean, nanoseconds are very small. But a 1.67x overhead feels large. I'd be interested in @syg's perspective (or that of his colleagues) as to whether this sort of thing feels like something we could optimize if needed in the future, or whether it's fundamentally going to be about 1.67x more work to do the whole async-to-sync-iterator dance vs. just iterating an array.

At a conceptual level, one angle is to wonder what `ReadableStream.from()` is supposed to mean. Some of the discussions in #1018 indicated it would be a general-purpose "feed me anything" API. Notably, the original idea had some behavior for blobs, and we discussed special-casing `ReadableStream.from(uint8Array)` or `ReadableStream.from(string)`---even if just to throw to avoid people getting a bunch of single-byte/code point chunks. But the current spec draft here leans hard into "treat the argument always as an async iterable". That has some elegance, but perhaps bad consequences for the string and Uint8Array case.

The relevance of the above paragraph is: if we decide to special-case more types, then special-casing arrays seems natural.

Also, I'm very excited that you created a draft CL!!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/1083#issuecomment-881027340