Re: [whatwg/encoding] Add Streams support (#72)

@jakearchibald Both ReadableStream and WritableStream contain a queue. A natural optimisation for TransformStream is to eliminate one or both of those queues. This works even if both ends of the pipe are JS. If either end of the pipe is an inbuilt stream then more exciting optimisations become possible.

The object returned by `TextDecoder.stream()` in my draft spec is an instance of TransformStream, so any optimisations that have been implemented for TransformStream automatically apply. I am assuming that TextDecoder will never be a subclass of TransformStream. Any optimisation that can be implemented for TransformStream can also be implemented for TextDecoder, but unless user agents carefully share implementation code with this in mind, optimisations applied to one will not automatically apply to the other.

Concretely speaking, in Chrome the implementation of TextDecoder is in C++ but TransformStream is due to be implemented in Javascript. My expectation is that general piping optimisations will apply to TextDecoder but optimisations specific to TransformStream are unlikely to be ported to TextDecoder unless there is specific demand.

I don't mean to suggest this is a showstopper. It is just something I am interested in feedback on.

With regards to:

```javascript
jsCreatedStream.pipeTo(decoder.writable, {preventClose: true}).then(() => {
  return fetchStream.pipeThrough(decoder);
});
```

I can describe how I think it will work in the optimisation proof-of-concept that @tyoshino has been working on. The `decoder` stream starts out with a Javascript source, so it is in "visible side-effects" mode. Even after switching to reading from `fetchStream` it remains in that mode until the data from `jsCreatedStream` has been completely drained. At that point it can transparently switch to "full optimisation" mode. Hopefully @tyoshino will correct me if I've got this completely wrong.

-- 
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/encoding/issues/72#issuecomment-251337039

Received on Tuesday, 4 October 2016 09:17:54 UTC