In the initial Haskell Wasm PR (#69), we introduced textToJSString and textFromJSString conversion functions which create an intermediate String (i.e. the famously inefficient [Char]).
There are examples of how to do better here. This is authored by the lead maintainer of the GHC Wasm backend, and may some day form the basis of some kind of Haskell equivalent to Rust's wasm-bindgen. But for now it's very much just a pre-alpha experiment.
If we really needed truly optimal performance we'd probably want to operate on Aeson.Value directly anyway, especially since JS uses UTF-16 internally (and Haskell's text library actually moved a few years ago from UTF-16 to UTF-8). We could even somehow go lower and allocate no intermediate structure at all.
Anyway, for the time being this isn't a bottleneck, since we're unlikely to be generating huge blobs of FLIR. So it doesn't seem worth the maintenance burden of vendoring the code. I'm just leaving these notes for posterity in case it ever becomes important.
In the initial Haskell Wasm PR (#69), we introduced
textToJSStringandtextFromJSStringconversion functions which create an intermediateString(i.e. the famously inefficient[Char]).There are examples of how to do better here. This is authored by the lead maintainer of the GHC Wasm backend, and may some day form the basis of some kind of Haskell equivalent to Rust's
wasm-bindgen. But for now it's very much just a pre-alpha experiment.If we really needed truly optimal performance we'd probably want to operate on
Aeson.Valuedirectly anyway, especially since JS uses UTF-16 internally (and Haskell'stextlibrary actually moved a few years ago from UTF-16 to UTF-8). We could even somehow go lower and allocate no intermediate structure at all.Anyway, for the time being this isn't a bottleneck, since we're unlikely to be generating huge blobs of FLIR. So it doesn't seem worth the maintenance burden of vendoring the code. I'm just leaving these notes for posterity in case it ever becomes important.