[heycam/webidl] String marshaling/interop for wasm and asm.js scenarios (#716)

I was talking with Ben Smith about reducing string marshaling costs for wasm applications talking to the DOM and other APIs. He mentioned that WebIDL-bindings has some mechanisms for this mentioned in it, but it might make sense to try and codify this and make it something that can be exposed to wasm or JS apps directly for interacting with things other than WebIDL APIs, and perhaps make it easier to get consistent performance.

My general thought here is that a well defined 'string view' primitive is needed, sort of like how typed array views represent a subset of an array buffer as a block of int32s or floats or what have you. A string view would represent a subset of an array buffer as a utf8 (or utf16?) string with a known length provided at construction time. You promise to the runtime that the contents of the view won't change and that you will call something like .dispose() on the view when done with it, and in exchange the runtime has opportunities to optimize the way it handles that string. Maybe copies still happen on invocation, etc, but many operations could potentially be much faster.

I know that v8 and spidermonkey both have some optimizations for small strings and keeping strings in alternate representations when possible, so it seems like there's room for some wins there. It's also great if you don't necessarily have to go through textdecoder or a manual fromcharcode rope nightmare just to pass a string to the Canvas API or to jQuery.

Would it make sense to try and codify something like this and align it with webidl-bindings? Even if it ends up being a 'ctor that selects a byte range and turns it into a js string internally' that probably provides chances for optimization over webidl having to do that marshal on every call.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/716