This is most likely a bad choose of a library to try and optimize with wasm. Basically, wasm has an overhead cost for every call. If wasm is called frequently and does very little work, than the overhead of calling it will out weigh any speed increase. A range is called repeatedly in a hot loop and does very little work so it would mostly like be slower in wasm.
As a side note, I believe modern JS runtimes are really good at optimizing things like hot for loops. Wasm disrupts this because the runtime has no idea what wasm is doing and isn't able to optimize the hot loop.
I agree that in retrospect, this probably wasn't to most idoneous choice. I wasn't too aware of the overhead of the interface, so that's something I've learnt. The lack of proper computation in the code itself (simply incrementing a counter) definitely surfaced that overhead in a more prominent way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is most likely a bad choose of a library to try and optimize with wasm. Basically, wasm has an overhead cost for every call. If wasm is called frequently and does very little work, than the overhead of calling it will out weigh any speed increase. A range is called repeatedly in a hot loop and does very little work so it would mostly like be slower in wasm.
As a side note, I believe modern JS runtimes are really good at optimizing things like hot for loops. Wasm disrupts this because the runtime has no idea what wasm is doing and isn't able to optimize the hot loop.
Thanks for your insights!
I agree that in retrospect, this probably wasn't to most idoneous choice. I wasn't too aware of the overhead of the interface, so that's something I've learnt. The lack of proper computation in the code itself (simply incrementing a counter) definitely surfaced that overhead in a more prominent way.