[umvi]

I feel like we need better WASM performance in go before we get WASI. In my experience go wasm performance is pretty bad, usually significantly worse than vanilla JS.

Rust (or really anything LLVM backed) is still probably the best WASM language in terms of performance and support, but .NET (don't forget to turn on AOT) is starting to get really good too (except for the fact that .NET compiler barfs out a bazillion files that the browser needs vs. 1 self contained .js or .wasm file which sucks if you are trying to build a self contained library like OpenCV.js)

[achille-roussel]

This is a good callout, although we probably won't be able to significantly improve the performance of Go compiled to WASM until WebAssembly evolves and introduces support for threads or stack switching so we can define goroutines based on those; right now the main reason Go compiled to WASM isn't in the ballpark of native perf is due to the stack switching emulation we have to do to get the cooperative scheduling of goroutines to work. We'll need WASM runtimes to offer more advanced primitives that we can rely on to implement those features of the Go language and produce much higher-quality code.

[grumpy_tired]

Would the emulation penalty still occur if Go routines aren't used at all? I have many small domain-specific libraries that I am planning to port to wasm. These libraries only allocate dynamic memory and differ anonymous functions.

[dgb23]

> usually significantly worse than vanilla JS

Can to elaborate?

This is can be true if you're interacting with browser API's such as the DOM frequently, because there's an overhead.

But I've seen several projects where (non-GC) WASM has improved performance significantly for specific tasks. You won't get native performance obviously.

[ramesh31]

>Can to elaborate?

The overhead of a runtime can easily make WASM code run slower than native JS functions. This only applies to GC languages like Go which require that.

>But I've seen several projects where (non-GC) WASM has improved performance significantly for specific tasks. You won't get native performance obviously.

You absolutely can if you're writing the raw WASM or compiling from C.

[DanielHB]

In my experience WASM performance is not that much better than JS in most cases, not so much because WASM is lacking, but because most JS runtimes performance is really, really good for a dynamic language.

When I measured C compiled with clang -O3 vs JS performance the only noteworthy speedup were on math-heavy tasks and even there only for integer-heavy math (floating point math was better than JS, but not by much). In a few cases the performance was worse. Notably recursive algorithms were _much_ better in WASM though even with algorithms that can't have tail-call optimisation (I guess function invocation has a lot of overhead in JS compared to C)

I think people over-value WASM speed. With regards to performance I imagine that the biggest gains compared to JS would be from not using garbage collection language. GC overhead, especially JS GC (compared to golang GC) can be painful in very large applications, especially in things were timings matter like 3d rendering. But GC can be optimised for in JS by avoiding allocations in the critical paths of the app