back

by anderspitman·8y ago·view on hn ↗
> In the most performance-sensitive contexts, JavaScript hinders rather than helps. Its dynamic type system and non-deterministic garbage collection pauses get in the way. Seemingly small code changes can result in drastic performance regressions if you accidentally wander off the JIT’s happy path.

I'm seeing this repeated more and more as a compelling case for using WASM. I've even repeated it myself. Does anyone know of examples of JS optimized for one VM not performing well in others, leading to a significant cost? I ask this as a Rust/WASM fanboy. Not doubting; just curious. I feel like I've already read a couple anecdotes but can't remember.

1 comments
I haven't done any performance-critical JavaScript for two years now and I know a lot a things have change with Turbofan, but I had been hitting slow paths of V8 so many times … The easiest to avoid were also the most painful when it comes to code organization : exception handling was so slow it was unusable. And it was affecting our ability to use modern JS, because the polyfil for `for of` or `async/await` had to use exception to comply with the spec. As a result we were stuck using ES5.1 for a really long time (because we needed to support mobile browsers, which are (or were at this point, at least) a new kind of IE6.