Announcing New Wasm_of_ocaml Optimisations

2025 was a good year for WASM support in OCaml! In February 2025, we announced the full release of Wasm_of_ocaml (also known as WSOO), a compiler translating OCaml bytecode to WebAssembly. Since then, our teams have been working on different improvements to the OCaml ecosystem, including boosting the performance of WSOO.

WSOO is already known for its speed. Users switching from Js_of_ocaml (JSOO), which translates OCaml bytecode to JavaScript, can expect significant performance improvements. Back in early 2025, Jane Street reported that they saw significant improvements using WSOO in comparison to JSOO. With the most recent optimisations WSOO is even faster!

You can try Wasm_of_ocaml for your own projects by visiting the manual, which includes installation instructions, on the Ocsigen website.

How Have We Made Wasm_of_ocaml Faster?

Almost as soon as the feature-complete release of Wasm_of_ocaml was out, a team at Tarides began working on optimisations for the library. Jérôme Vouillon has led the way, testing each change and measuring the resulting performance improvements. Let’s take a look at some of the PRs that have come out of this effort and what has changed:

• Inlining pass: Jérôme rewrote the inlining pass to adjust its behaviour in certain cases. The change avoids inlining code in a loop that WASM engines can’t optimise because V8 currently has no way to switch to a more efficient code while executing a loop. It is now also more assertive in inlining functors and functions, including List.fold_left. The PR is #1935.

• The OCaml standard library contains a Bigarray module that offers an API to manipulate an array of numerical values (integers of floating point values of various sizes). When compiling a program to WebAssembly, Bigarray operations are translated behind the scenes as operations on Javascript “typed arrays”.Up to now, these operations were implemented in terms of direct access to these arrays, but this method went through calls to Javascript functions that incurred some overhead.

  Javascript offers an alternative API called DataView, whose operations are recognised and compiled as direct memory accesses by Wasm engines such as Google’s V8. We have modified the backend function supporting Bigarray to use DataView and benchmarked it with a program performing millions of Bigarray accesses, and we are observing an impressive 3.9x speedup.

  Check out PR #1979 to look more closely at the changes.

• Function call optimisations: There are a whole host of changes targeting function calls:

  • PR #2041 optimises the representation of closures using more precise types.
  • PR #2044 optimises calls to a statically known function.
  • PR #2059 omits the code pointer when it is not used (because of the previous optimisation). This reduces the amount of memory allocated by the program, but also allows Binaryen to perform some global optimisations.

• Integer optimisations: Wasm_of_ocaml uses 31-bit integers to allow for a uniform representation of integers and references. The integers have to be converted to 32-bit integers to perform numeric operations. PR #2032 optimises this workflow by avoiding unnecessary conversions between 31 and 32-bit integers, which speeds up performance.

• Number unboxing: Avoids boxing numbers (both within functions #2069 and outside of functions #2101) when the boxed value is not used. The change significantly improved the microbenchmarks almabench and fft.

• Number comparisons and bigarray operations: Specialisation of number comparisons and bigarray operations in PR #1954, based on a type analysis, optimises the performance of functions. Future work to improve on this optimisation centres around using hints from the OCaml compiler.

Hopefully, you now have a good sense of just how much has been tweaked and improved to make WSOO faster! But, you may ask, just how much faster are we talking about?

Benchmarks

Several of these changes have contributed to improving WSOO's performance, visualised in the graphs below. The first one is the CAMLboy benchmark, showing steady improvement over time until it was one third faster.

The second graph show the performance improvement for some selected microbenchmarks. Numerical benchmarks, like almabench, fft, nucleic, and raytrace, show a nice improvements. The integer optimisation helps for fib, quicksort, and fft. The raytrace microbenchmarks show the most improvement, thanks to better inlining and number unboxing across function.

What’s Next for Wasm_of_ocaml?

Look out for the next milestone for WSOO: adding WASI 0.1 support! The team have implemented an alternative runtime based on WASI, a group of API specifications for software compiled to the WebAssembly standard (W3C). WASI support will enable users to execute OCaml programs in new environments, from browsers to clouds to embedded devices. The PR is still open and feedback is always welcome.

Furthermore, another one of the team’s goals is to test an implementation of effect handlers based on the Stack Switching proposal, you can find the details in #1882.

Lastly, the team has more work planned to improve the performance of both Js_of_ocaml and Wasm_of_ocaml in 2026.

Until Next Time

Remember to visit the manual on Ocsigen’s website to learn more about Wasm_of_ocaml and to get started with the compiler if you haven’t already. The WSOO team is always keen to hear feedback and figure out how they can improve the user experience. Please share your thoughts and experiences with the compiler on OCaml’s discussion forum!

You can connect with us on Bluesky, Mastodon, Threads, and LinkedIn or sign up for our mailing list to stay updated on our latest projects. We look forward to hearing from you!