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

BYOB support for controlTransferIn, transferIn and isochronousTransferIn #217

Open
reillyeon opened this issue Apr 8, 2022 · 2 comments

Comments

@reillyeon
Copy link
Collaborator

Profiling done by a developer reporting a Chromium issue shows that allocating lots of small buffers for transfer results creates significant GC pressure when transfering data at high speed. We should consider supporting a "bring your own buffer" mode similar to what is done in the WHATWG Streams API.

We will need to measure whether this results in a practical improvement given that transfer results must also allocate an IDL dictionary for the result metadata.

@reillyeon
Copy link
Collaborator Author

I checked with the developers of the Streams API and they say that reducing the amount of memory allocated, even just a little bit, is helpful and so I think this is worth prototyping and measuring.

@RReverser
Copy link
Contributor

RReverser commented Nov 22, 2023

I don't have specific usecase where this would be necessary, but yes, BYOB could be interesting for performance reasons as well as for simplifying Wasm bridge code.

One other thing that could be helpful to track here is to allow using SharedArrayBuffer-backed data in WebUSB API.

This is a common issue with Web APIs that they try to protect developers from race condition and tend to restrict accepted typed arrays to non-shared only, but in practice it means that all users of multithreaded Wasm have to allocate a copy of the data they have just to pass it to the Web API, and then implementations like Chromium copy it yet again to send over Mojo or similar bridges to native code.

This is pretty wasteful, especially given that code compiled to Wasm usually has its own logic for dealing with any races and wouldn't have issues with unexpected mutations in practice - even if it did, at worst this would be a logic errors as typed arrays and Wasm memory are already bound-checked.

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

No branches or pull requests

2 participants