Re: [whatwg/encoding] Make decode() and encodeInto() accept SharedArrayBuffer-backed views (#172)

> If the most obvious path to for-sure non-UB implementation is to make the DOM code use a presently-slower-than-memcpy replacement for memcpy with an intermediate buffer, is there any reason why that would be better than having the JS glue code between wasm and WebIDL make the intermediate copy within the JS engine?

Off-issue discussion and investigation has convinced me that even if the first round of host implementation wasn't any faster than having the site-provided code make a copy, there's enough opportunity for subsequent host-side optimization for this spec change to make sense.

-- 
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/172#issuecomment-470888478

Received on Friday, 8 March 2019 10:54:09 UTC