 New year has just started and with it new resolutions to accomplish. How about learning how to use WebAssembly and get a performance boost? This article continues a serie of articles that we are writing about performance, go and check “[How to get a performance boost using Node.js native addons](https://medium.com/developers-writing/how-to-get-a-performance-boost-using-node-js-native-addons-fd3a24719c85)” and “[A 1300% performance gain with Ruby time parsing optimization!](https://medium.com/@devlucky/ruby-time-parsing-optimization-524622354201)” ✌️ I want to demonstrate to you today how to create and use WebAssembly modules and later on consume them from the browser as if they were js modules. In order to do so I will take the Fibonacci algorithm, which I [already discussed here](https://medium.com/developers-writing/fibonacci-sequence-algorithm-in-javascript-b253dc7e320e) and I will benchmark its performance running as a normal javascript function and as a WebAssembly module. ### Implementations We are going to cover the same 3 techniques we already covered in the previous article: * Loop * Recursion * Memoization The following snippets cover those implementations in Javascript and C. > Javascript > C I will not explain how these functions work since this post is not about that. If you want to know more about it check [this](https://en.wikipedia.org/wiki/Fibonacci_number) [or](http://stackoverflow.com/questions/8965006/java-recursive-fibonacci-sequence) [this](https://en.wikipedia.org/wiki/Memoization). ### A bit of history * **WebAssembly** was born with the premise of creating a safe, portable and fast to load and execute format suitable for the web. WebAssembly is not a programing language, it is a **compilation target** which has both text and binary specs. This means that low level languages like C/C++, Rust, Swift, etc. can be compiled with a WebAssembly output. It shares the stack with javascript, that’s why it is different from things like [java-applets](https://en.wikipedia.org/wiki/Java_applet). Also its [design](https://github.com/WebAssembly/design) is a community effort, with all browser vendors working on it. * **Emscripten** is a LLVM-to-JavaScript Compiler. That means that languages like C/C++ or any language that speaks LLVM can be compiled to JavaScript. It provides a set of Apis to port your code to the web, the project has been running for years and was typically used to port games to the browser. Emscripten achieves its performance outputting **asm.js** but recently it has integrated successfully a WebAssembly compilation target. * **ASM.js** is a low-level optimized subset of Javascript, linear memory access via TypedArrays and type annotations. Again, it is not a new programing language. Any browser without asm.js support will still work when running asm.js, it will just not get the performance benefits. As of **10–01–2017,** the current status is that it works in [Chrome Canary](https://www.chromestatus.com/features/5453022515691520) and [Firefox](https://hacks.mozilla.org/2016/03/a-webassembly-milestone/) under a feature flag and is under development in [Safari](https://webkit.org/status/#specification-webassembly). And from the V8 side, it just [got enabled by default](https://chromium.googlesource.com/v8/v8/+/34b63f050b1a247bb64ddc91c967501ce04e011f) 🚀. This video from the [Chrome Dev Summit 2016](https://www.youtube.com/playlist?list=PLNYkxOF6rcIBTs2KPy1E6tIYaWoFcG3uj) shares the current state of JavaScript and script tooling in V8, and discusses the future with WebAssembly.  ### Building + Loading module Let’s take a look at how we transform our C program into [wasm](http://webassembly.org/docs/semantics/). To do so, I decided to go with the [Standalone output](https://github.com/kripken/emscripten/wiki/WebAssembly-Standalone) which instead of returning a combination of .js and WebAssembly, will return just WebAssembly code without the system libraries included. This approach is based on Emscripten’s [side module](https://github.com/kripken/emscripten/wiki/Linking) concept. A side module makes sense here, since it is a form of dynamic library, and does not link in system libraries automatically, it is a self-contained compilation output. `$ emcc fibonacci.c -Os -s WASM=1 -s SIDE_MODULE=1 -o fibonacci.wasm` Once we have the binary we just need to load it in the browser. To do so, [WebAssembly js api](https://github.com/WebAssembly/design/blob/master/JS.md) exposes a top level object **WebAssembly** which contains the methods we need to [compile](https://github.com/WebAssembly/design/blob/master/JS.md#webassemblycompile) and [instantiate](https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyinstance-constructor) the module. Here is a simple method based on [Alon Zakai](https://medium.com/@kripken) [gist](https://gist.github.com/kripken/59c67556dc03bb6d57052fedef1e61ab) which works as generic loader: Cool thing here is that everything happens asynchronously. First we fetch the file content and convert it into an [ArrayBuffer](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer) which contains the raw binary data in a fixed length. You can’t manipulate it directly and that’s why we then pass it to **_WebAssembly.compile_** which returns a [WebAssembly.Module](https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymodule-constructor) which you can finally instantiate with **_WebAssembly.Instance_**. Take a look into the [Binary-encoding](https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md) format that WebAssembly uses if you want to go deeper into that topic. ### Benchmarking Now is time to see how we can use the module and test its performance against the javascript implementation. We will use 4**0** as input to be consistent with what we did in our previous article: > Results (You can check a live demo [here](https://zzarcon.github.io/WebAssembly-demo/)) JS loop x 8,605,838 ops/sec ±1.17% (55 runs sampled) JS recursive x 0.65 ops/sec ±1.09% (6 runs sampled) JS memoization x 407,714 ops/sec ±0.95% (59 runs sampled) Native loop x 11,166,298 ops/sec ±1.18% (54 runs sampled) Native recursive x 2.20 ops/sec ±1.58% (10 runs sampled) Native memoization x 30,886,062 ops/sec ±1.64% (56 runs sampled) Fastest: Native memoization Slowest: JS recursive Interesting facts: * Best C implementation is 375% faster than best JS implementation. * Fastest implementation in C is memoization while in JS is loop. * Second fastest implementation in C is still faster than the JS faster one. * Slowest C implementation is 338% times faster than the JS slowest one. ### Conclusion Hope you guys have enjoyed this introduction to WebAssembly and what you can do with it today. In the next article I want to cover non standalone modules, different techniques to communicate from C <->JS and Link & Dynamic Linking. Don’t forget to check the [WebAssembly Roadmap](http://webassembly.org/roadmap/) and [Emscriptend Changelog](https://github.com/kripken/emscripten/blob/master/ChangeLog.markdown) to stay up to date with the latest updates as well as the [Getting Started tutorial](http://webassembly.org/getting-started/developers-guide/). Happy 2017 🐣 [](https://twitter.com/zzarcon) You can follow me on Twitter or Github @zzarcon