SebastianVerified account

Good example, we've surfaced a new ability to allow people to opt into their own crypto hash algo instead of "crypto". Those who chose something like farmhash, metrohash, xxhash as a wasm module, saw obnoxious perf wins on incremental and initial build times.

We've replaced JS implemented parsers with direct interop of from native Reason to Flow native parsers and saw HUGE wins for parser heavy workflows. Certainly over 5x improvements of the full end-to-end.

This isn't file IO heavy though - it's memory/CPU intensive, so YMMV depending on the nature of the work.

Keep in mind ocamlopt is *full* native. There is no VM, no bytecode to load/parse at app startup time. The generated assembly code resembles the structure of your program - like when you disassemble a compiled C program.

This is really tempting to bite on it. Pardon me for not understanding anything about ocamlopt, but does this run cross plat seamlessly or is there some targets concerns?

It’s okay people often don’t know this about ocamlopt. It runs on every major processor architecture, compiles full Native binaries for every major OS. Like any full native compiler it means you distribute binaries per platform. This is what Flow does for their releases.

That means you can’t pick up a Mac binary and run it on windows just like you can’t pick up a Chrome/V8 binary for Linux and run it on Windows. Instead you distribute binaries for all popular OS’s.

The tooling for *easily* generating those binaries for Windows is still under development but it’s definitely possible and Flow does it for every release.