[chambers]

I found WASM slower than expected. I wrote some WASM logic functions recently which I thought would perform better than their native JS equivalent. For example, take a large array and "pivot" it in 10ms instead of a 100ms.

What I found was the JS version was a bit faster than the compiled WAT. Yikes.

EDIT: I think I'll try debugging it more

[ridiculous_fish]

At $WORK we use SQLite in WASM via the official ES module, running read-only in browser.

The performance is very poor, perhaps 100x worse than native. It's bad enough that we only use SQLite for trivial queries. All joins, sorting, etc. are done in JavaScript.

Profiling shows the slowdown is in the JS <-> WASM interop. This is exacerbated by the one-row-at-a-time "cursor" API in SQLite, which means at least one FFI round-trip for each row.

[chambers]

Yup, I've tested and seen WASM SQlite's slowness myself. But I don't think it's a SQLite problem per se.

I heard WebSQL, which used SQLite, was at least 10x faster than WASM SQLite. Probably even more.

[fancyswimtime]

the answer will be; depends what ur doing. There is a cost communicating with a worker