I just spent two days (🥲) rewriting a hot path in rust to see how much better it would perform using wasm. The answer: Not at all!

I'm kind of sad I'm not getting my magical performance boost, but otoh I don't have to maintain an extra piece of tooling in my codebase now, so that's gotta be worth something.

Note though that this was not really rust's fault and neither was it wasm's. Basically my algorithm creates a whole bunch of `new BoxCollider()` instances as it is running, so the hot path turned out to be a lot less 'hot' than I thought.
I decided to put more time into this for some reason. I rewrote the hot path (again) in js but this time closely mimicking the way it was implemented in rust.
The js version takes significantly longer, but if you ignore serialization (which you typically only need with wasm), it's starting to get a lot closer to what rust can achieve.
Also note the big gap at the start of the wasm runs, god knows what the cpu is doing there.

So in conclusion. The actual functional piece of code seems to be running roughly x2.8 times as fast! But with all the extra overhead it's more like x1.25 as fast sadly.

The (unminified) js file is 4.7kB, whereas the wasm + gluecode takes up 31.5kB. So I think the trade-off is probably not worth it for our case.