Support for TC-39's async iteration proposal?

Question

Support for TC-39's async iteration proposal?

Closed this issue 6 years ago · 6 comments

Would it be possible to extend asynciterator to support TC-39's async iteration proposal? It is starting to be implemented by browsers and has landed as a new way to consume streams in Node.js 10.x .

Answer 1 · 2018-10-01T09:38:02.000Z

I might add interface support, but (and this is a bit but) async iteration is a lot slower than asynciterator. It has been a deliberate choice to develop asynciterator, even though the asyc iteration effort was going on, for performance reasons.

So while you could then for await over an AsyncIterator, it would not be the preferred way in performance-critical applications.

My colleague @joachimvh did some testing earlier this year: LinkedDataFragments/HDT-Node#9 (comment)

Answer 2 · 2018-10-01T09:52:45.000Z

@RubenVerborgh I see! Thank you for pointing me to that.

Answer 3 · 2018-10-06T10:16:54.000Z

The linked comment seems to talk about testing the transpiled versions of async generators, though; the native performance should be better.

Answer 4 · 2018-10-06T14:45:23.000Z

@joachimvh Do we have native performance tests?

Answer 5 · 2018-10-08T09:39:00.000Z

I just removed the transpilation step now and it did improve but is still much slower than AsyncIterator (usual disclaimer of this not being the most extensive tests ever etc.)

Answer 6 · 2018-12-05T11:40:12.000Z

Perphaps relevant for this discussion: node 10 has (experimental) support for using a readable stream as an async iterator. This would not solve any possible performance issue, but it could mean we wouldnt have to implement an async iterator interface and a streaming interface.