Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identity transform performance and ArrayBufferView ownership #323

Closed
tyoshino opened this issue Apr 8, 2015 · 1 comment
Closed

Identity transform performance and ArrayBufferView ownership #323

tyoshino opened this issue Apr 8, 2015 · 1 comment

Comments

@tyoshino
Copy link
Member

tyoshino commented Apr 8, 2015

(based on @yutakahirano's analysis)

An identity transform can be designed to pass the ArrayBufferViews (after detaching) written to the writable side as-is to the readable side. This is good since no copy happens.

We have three choices in implementing this:

  • (a) on .write(), the transform takes ownership of the ArrayBufferView permanently
  • (b) on .write(), the transform takes ownership but returns it later (notify ownership release by fulfilling the promise returned by .write())
  • (c) on .write(), the transform reads out all the bytes from the ArrayBufferView. It never takes ownership.

(a) allows the transform to pass the ArrayBufferView as-is (after detaching) to the consumer through ReadableStream without ack capability (non-BYOB), but disallows the producer to reuse the buffer.

(b) allows the producer to reuse the buffer, but if the readable side is ReadableStream without ack capability (non-BYOB), there's no way to get the buffer returned by the consumer, so, we need to copy data inside the transform. To eliminate copy, we need ReadableStream with ack.

When BYOB reading is used, we anyway need to copy bytes.

@tyoshino
Copy link
Member Author

Closing this issue as the topic is covered by #329. (c) has been merged into the matrix #329 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants