I'm not the OP but I can confirm in my own project, we found about a 10x performance gap between AssemblyScript and TypeScript. In essence, we're working on a rewrite of DNAVisualization.org[1][2], a serverless web tool for the interactive inspection of raw DNA sequences. We hoped that WASM would give us a performance boost but have been generally disappointed with both the performance and the amount of complexity involved in getting the tooling to work.

We did do a benchmark[3] and, unless we made an error (likely, given that all of us are new to WASM), found that JS was much faster for our simple algorithms. WASM had the approximate performance of our original pure Python implementation[4], so not great.

[1]: https://dnavisualization.org [2]: https://academic.oup.com/nar/article/47/W1/W20/5512090 [3]: https://github.com/Lab41/dnaviz/tree/benchmarks/benchmarks/a.... [4]: https://github.com/Lab41/squiggle

I made PR which suggest some changes and fixes: https://github.com/Lab41/dnaviz/pull/21

As you can see AssemblyScript approx 4x-4.5x times faster now

Unfortunately, no, it's a commercial closed-source project. I profiled both JS and WA versions, the hottest methods took basically the same amount of time in both versions, except that WA build additionally spend ~25% of all time in __retain or something like that.

Do you intensive use small objects like Vec3, Quaternion and etc? AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now. All this significantly reduce ARC / memory pressure. But my assumption it could be also wrong measurement. Most of people uses benchmark.js which also measure js <-> wasm interop overhead which usually main bottleneck.

> AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now.

Yes, I do use a lot of small objects. That's an interesting information, I'll keep an eye on multi-value proposal, thank you!

> Most of people uses benchmark.js which also measure js <-> wasm interop overhead which usually main bottleneck.

Nope, I loaded all the data into WA module upon initialization and don't perform any additional synchronization between WA and JS afterwards (which is also kind of unfair advantage for WA).