Skip to content
Permalink
Browse files

Host-bindings proposal has been renamed to the interface types proposal

  • Loading branch information
twilco committed Dec 31, 2019
1 parent 554057f commit 61643e20416985cb348007a4d860761f63742072
Showing with 2 additions and 2 deletions.
  1. +2 −2 _posts/2019-01-14-A-Tale-of-Performance---Javascript,-Rust,-and-WebAssembly.md
@@ -445,7 +445,7 @@ To answer this question, there's something else we need to know about WebAssembl
`wasm-bindgen` solves this problem by automatically creating code that takes our rich types, like the string version of our dates, and converts them into types that WebAssembly can work with. We see this in the `passStringToWasm` function, which takes our string, turns it into bytes, and copies those bytes from JavaScript's heap into WebAssembly's linear memory. The act of allocating space for and copying of the bytified version of our string is very expensive, especially when done frequently in small increments (which is, unfortunately, exactly what we're doing). We'll see just how expensive this is later on.
Eventually this glue code will not be necessary thanks to the [host bindings proposal](https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md){:target="_blank"}. Among many other things, the host bindings proposal provides a standard way to create rich types, such as strings and JSON, when passed some function that can allocate memory (`wee_alloc`, anyone?). Host bindings will also [unlock faster than JavaScript DOM access](https://github.com/rustwasm/wasm-bindgen#features){:target="_blank"} since WebAssembly functions are statically checked and thus do not require the runtime-type checks that JavaScript functions do.
Eventually this glue code will not be necessary thanks to the [interface types proposal](https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md){:target="_blank"}. Among many other things, the interface types proposal provides a standard way to create rich types, such as strings and JSON, when passed some function that can allocate memory (`wee_alloc`, anyone?). Interface types will also [unlock faster than JavaScript DOM access](https://github.com/rustwasm/wasm-bindgen#features){:target="_blank"} since WebAssembly functions are statically checked and thus do not require the runtime-type checks that JavaScript functions do.
## Back to JavaScript
@@ -536,7 +536,7 @@ So, you might be wondering - if we're doing things the wrong way, how might we d
> As a general rule of thumb, a good JavaScript↔WebAssembly interface design is often one where large, long-lived data structures are implemented as Rust types that live in the WebAssembly linear memory, and are exposed to JavaScript as opaque handles. JavaScript calls exported WebAssembly functions that take these opaque handles, transform their data, perform heavy computations, query the data, and ultimately return a small, copy-able result. By only returning the small result of the computation, we avoid copying and/or serializing everything back and forth between the JavaScript garbage-collected heap and the WebAssembly linear memory.
In our current implementation, all of our data lives within JavaScript's heap, which is currently inaccessible from WebAssembly's linear memory space (this, too, will be fixed upon implementation of the host bindings proposal). As suggested in the quote, a better implementation would instead have our table data and the entirety of our sorting logic reside inside WebAssembly. Rather than hitting an endpoint for the table data from JavaScript, we would do so from Rust, perhaps via some exposed-to-Javascript handle. This precludes the need for any copying, since all of our data now lives and is manipulated entirely within WebAssembly's memory space.
In our current implementation, all of our data lives within JavaScript's heap, which is currently inaccessible from WebAssembly's linear memory space (this, too, will be fixed upon implementation of the interface types proposal). As suggested in the quote, a better implementation would instead have our table data and the entirety of our sorting logic reside inside WebAssembly. Rather than hitting an endpoint for the table data from JavaScript, we would do so from Rust, perhaps via some exposed-to-Javascript handle. This precludes the need for any copying, since all of our data now lives and is manipulated entirely within WebAssembly's memory space.
Without the need to copy, things should be much faster. Problem solved, right? Well, not exactly. We still need all the table data on JavaScript's end to actually _display_ it, don't we? Well, fortunately for us, while WebAssembly cannot currently access JavaScript's heap, JavaScript _can_ access WebAssembly's linear memory space via the [WebAssembly.Memory API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Memory){:target="_blank"}. In even better news, `wasm-bindgen` exports the memory of our WebAssembly instance as a standard module, meaning we can `import` just as easily as we can anything else.

0 comments on commit 61643e2

Please sign in to comment.
You can’t perform that action at this time.