This is the sixth part in a series on WebAssembly and what makes it fast. If you haven’t read the others, we recommend starting from the beginning.
On February 28, the four major browsers announced their consensus that the MVP of WebAssembly is complete. This provides a stable initial version that browsers can start shipping.
This provides a stable core that browsers can ship. This core doesn’t contain all of the features that the community group is planning, but it does provide enough to make WebAssembly fast and usable.
Even in the initial release, WebAssembly will be fast. But it should get even faster in the future, through a combination of fixes and new features.
Improving WebAssembly performance in browsers
Some speed improvements will come as browsers improve WebAssembly support in their engines. The browser vendors are working on these issues independently.
Faster function calls between JS and WebAssembly
Currently, calling a WebAssembly function in JS code is slower than it needs to be. That’s because it has to do something called “trampolining”. The JIT doesn’t know how to deal directly with WebAssembly, so it has to route the WebAssembly to something that does. This is a slow piece of code in the engine itself, which does setup to run the optimized WebAssembly code.
This can be up to 100x slower than it would be if the JIT knew how to handle it directly.
You won’t notice this overhead if you’re passing a single large task off to the WebAssembly module. But if you have lots of back-and-forth between WebAssembly and JS (as you do with smaller tasks), then this overhead is noticeable.
Faster load time
JITs have to manage the tradeoff between faster load times and faster execution times. If you spend more time compiling and optimizing ahead of time, that speeds up execution, but it slows down start up.
There’s a lot of ongoing work to balance up-front compilation (which ensures there is no jank once the code starts running) and the basic fact that most parts of the code won’t be run enough times to make optimization worth it.
Since WebAssembly doesn’t need to speculate what types will be used, the engines don’t have to worry about monitoring the types at runtime. This gives them more options, for example parallelizing compilation work with execution.
In Firefox we’re working on a two-compiler system. One compiler will run ahead of time and do a pretty good job at optimizing the code. While that’s running code, another compiler will do a full optimization in the background. The fully-optimized version of the code will be swapped in when it’s ready.
Adding post-MVP features to the spec
One of the goals of WebAssembly is to specify in small chunks and test along the way, rather than designing everything up front.
This means there are lots of features that are expected, but haven’t been 100% thought-through yet. They will have to go through the specification process, which all of the browser vendors are active in.
These features are called future features. Here are just a few.
Working directly with the DOM
Currently, there’s no way to interact with the DOM. This means you can’t do something like
element.innerHTML to update a node from WebAssembly.
Shared memory concurrency
One way to speed up code is to make it possible for different parts of the code to run at the same time, in parallel. This can sometimes backfire, though, since the overhead of communication between threads can take up more time than the task would have in the first place.
If you read other posts or watch talks about WebAssembly, you may hear about SIMD support. The acronym stands for single instruction, multiple data. It’s another way of running things in parallel.
SIMD makes it possible to take a large data structure, like a vector of different numbers, and apply the same instruction to different parts at the same time. In this way, it can drastically speed up the kinds of complex computations you need for games or VR.
This is not too important for the average web app developer. But it is very important to developers working with multimedia, such as game developers.
Many code bases in languages like C++ use exceptions. However, exceptions aren’t yet specified as part of WebAssembly.
If you are compiling your code with Emscripten, it will emulate exception handling for some compiler optimization levels. This is pretty slow, though, so you may want to use the
DISABLE_EXCEPTION_CATCHING flag to turn it off.
Once exceptions are handled natively in WebAssembly, this emulation won’t be necessary.
Other improvements—making things easier for developers
Some future features don’t affect performance, but will make it easier for developers to work with WebAssembly.
- First-class source-level developer tools. Currently, debugging WebAssembly in the browser is like debugging raw assembly. Very few developers can mentally map their source code to assembly, though. We’re looking at how we can improve tooling support so that developers can debug their source code.
- Garbage collection. If you can define your types ahead of time, you should be able to turn your code into WebAssembly. So code using something like TypeScript should be compilable to WebAssembly. The only hitch currently, though, is that WebAssembly doesn’t know how to interact with existing garbage collectors, like the one built in to the JS engine. The idea of this future feature is to give WebAssembly first-class access to the builtin GC with a set of low-level GC primitive types and operations.
scripttag. Once this feature is added, a tag like
<script src=url type="module">could work even if url points to a WebAssembly module.
WebAssembly is fast today, and with new features and improvements to the implementation in browsers, it should get even faster.
About Lin Clark
Lin works in Advanced Development at Mozilla, with a focus on Rust and WebAssembly.