More concrete examples of "optimization" of pipeTo

[tyoshino]

Potential targets of optimization

• TextEncodingTransformByteStream
• IdentityTransformByteStream
• BufferingTransformByteStream
• ByteCountingIdentityTransformByteStream
  • The wrapper is not a pure identify transform but with observation functionality.
  • In yutakahirano/fetch-with-streams#37 (comment), use of a wrapper is proposed for counting the number of bytes consumed from a Request/Response.

Skipping JS processing between a ReadableByteStream and a WritableByteStream

Skip JS code invocation (write(), read(), etc.) and does the following internally.

Sink exposes a memory region for write

1. destMemory = sink.getMemoryToWrite()
2. source.generate(destMemory)
3. sink.notifyWritten()

Source exposes a memory region where data for consuming is stored

1. sourceMemory = source.getMemoryToRead()
2. sink.consume(sourceMemory)
3. source.notifyConsumed()

Both takes memory

1. tempMemory = allocate()
2. source.generate(tempMemory)
3. sink.consume(tempMemory)

sendfile(2) style

1. transfer(lowerLayerSourceDescriptor, lowerLayerSinkDescriptor)

Skipping an "identity" transform byte streams completely

a.pipeTo(id, options0);
id.pipeTo(b. options1);

Copy data from a to b directly.

Issues:

• Thread-safety: a.pipeTo(id) and id.pipeTo(b) may happen in different threads.
• How to observe bytes for ByteCountingIdentityTransformByteStream?

[tyoshino]

We've decided to introduce isDisturbed, not byte counting system. So, we should reinvestigate how we set isDisturbed.

[tyoshino]

Regarding how we realize postMessage()-ing streams #244, we should consider how to deal with invocation of an optimized pipeTo() logic for cross thread case.

[tyoshino]

Please take a look at my strawman API for allowing pipeTo optimization at #511.