Source code

JS / wasm-bindgen comparison

These benchmarks are meant to compare WebAssembly costs using raw wasm files and wasm-bindgen itself against the JS equivalents. These microbenchmarks aren't really representative of WebAssembly performance, but can be useful data points about how expensive it is to cross boundaries for example.

For all benchmarks higher numbers are better numbers.

Benchmark wasm-bindgen JS *.wast
Call a thunk (?)

This benchmarks tests out how long it take JS to call a thunk in the given language. For example JS will call a JS thunk or JS will call a Wasm function that does nothing.

Call an adder (?)

This benchmarks tests out how long it take JS to call a function in the target language which adds two numbers and returns the result. This is likely to be similar to the previous benchmark in terms of results, but it's thought that some extra computation may show overheads differently.

Call a JS thunk (?)

This benchmarks tests out how long it takes to call a JS function 10,000 times. Each language/framework has a function which takes a parameter of how many times to call an imported JS function. Remember that JS itself benefits from inlining, where as JS cannot be inlined into WebAssembly. In these cases the imported function performs no work, it just returns immediately.

Call a JS function which adds (?)

This benchmark is similar to the previous thunk benchmark except that this time the imported function will add its two arguments and returns the result. This helps measure the overhead of sending data like integers back and forth.

Calculate Fib(40) (?)

This benchmarks calculates the 40th fibonacci number. It in theory should favor Wasm since Wasm is "better a compute", but a good JIT will probably make the code roughly equivalent.

Access Node.firstChild (?)

This benchmark attempts to see the cost of accessing a DOM property from both JS and WebAssembly. We access the DOM property as fast as possible in WebAssembly and otherwise just access it as a normal property in JS.

Access Node.nodeType (?)

This benchmark attempts to see the cost of accessing a DOM property from both JS and WebAssembly. We access the DOM property as fast as possible in WebAssembly and otherwise just access it as a normal property in JS.

Count types of nodes on a page (?)

This is intended to be a "flavorful DOM benchmark" which exercises DOM functionality from WebAssembly, specifically counting the number of types of each node on a page.

wasm-bindgen benchmarks

These benchmarks don't compare against JS but are instead more intended to be compared against each other, across browsers, or across versions of wasm-bindgen.

Benchmark Result
Access Node.nodeType with final (?)

This is similar to the Node.nodeType benchmark above except that it uses the final attribute in wasm-bindgen.

Access Node.nodeType with structural (?)

This is similar to the Node.nodeType benchmark above except that it uses the structural attribute in wasm-bindgen.

Call a custom JS class Foo.bar method with final (?)

This is similar to the Node.nodeType benchmark above except that it's not calling a DOM method but rather a custom JS class's method.

Call a custom JS class Foo.bar method with structural (?)

This is similar to the Node.nodeType benchmark above except that it's not calling a DOM method but rather a custom JS class's method.

Call a custom JS function with a string enum value parameter (?)

Benchmarks the speed of passing string enums to javascript