Port to AssemblyScript some code for performance
darky opened this issue · comments
On one geo project, instead of using geolib isPointInPolygon I rewrite some code to Rust and compile it to WebAssembly like this toy project: https://github.com/darky/rstar-wasm
Performance gain 30-200 RPS -> 4700-5100 RPS
Maybe need to rewrite some performance critical parts with https://github.com/AssemblyScript/assemblyscript
You can drastically increase performance of rbush ;)
I doubt that. Most of my experiments with WebAssembly have produced code that's slower than the JS implementation (if you optimize the latter well). I'll be happy for you to prove me wrong though — feel free to port. :)
I play with AssemblyScript and do successful port of this project: https://github.com/mourner/quickselect
Performance decrease of wasm version was ~4-5x ( ~120ms -> ~450ms ) via npm run bench
I investigate it and see that so many cost is __allocArray and __getArray ( ~0.25ms and ~0.13ms per call)
But call of wasm quickselect very cheap (0.004ms instead of 0.075ms of js version)
Maybe later transform from js to wasm will be cheaper.
Now, I think wasm win for long running stateful applications, when you can on startup initialise wasm side and do blazing fast calls of wasm functions from js :)
__getArray is slow becouse use reflection under the hood. Better use typed array (Float64Array for example) on AS side and __getFloat64Array on host side. Also with using unchecked like unchecked(arr[i] = x) and v = unchecked(arr[i]) for array's access you could speed up this more
@MaxGraey thanks, __getFloat64Array improve performance 2x (~0.05ms)
But it so slow yet on __getArray and __getFloat64Array .
I think need to wait https://github.com/WebAssembly/interface-types implementation in AssemblyScript and V8 engine.
Yes. interop cost in WebAssembly is weakest (slowest) part currently. So for best result better port whole or meaningful part of program instead just some hot but small paths