3 ms·

This makes sense to me; graphs made of JavaScript objects are not going to be as fast as C, although I think knowledge of how the JIT works can still help you g

This makes sense to me; graphs made of JavaScript objects are not going to be as fast as C, although I think knowledge of how the JIT works can still help you get a lot closer than 10x (e.g. ensuring everything is monomorphic). Now if you implemented a b-tree completely inside of a typed array, instead of using JavaScript objects as the nodes, that would be how you would approach C speeds. But if you need a lot of custom data structures, WASM is probably a better choice at that point.

josephg 4y ago
About a decade ago I hand-ported the chipmunk2d physics engine to javascript. After porting it, I tried about 30 different things trying to make the code run faster. Some things I tried made it faster. Some made it slower. The most performance-critical section is the "arbiter applyImpulse" physics code[2], which is all math. I tried putting everything in as big TypedArray to avoid all the object lookups, but performance got slightly worse, not better. I still have no idea why. I think the reason is that the optimizer couldn't optimize the typedarray lookups at the time. Not in the same way it can optimize math on normal objects. Maybe v8 is more clever now? I dunno! The biggest performance win I got was from inlining vector fields. Chipmunk heavily uses {x,y} 2d vectors. Lots of objects looked like this: {pos: {x, y}, velocity: {x, y}, ...}. Flattening everything to this {posx, posy, velocityx, velocityy, ...} made the code uglier. But it caused a massive performance improvement because it reduced the number of objects allocated on the heap. (This one change reduced the number of heap allocations by about 70% from memory, and it caused a double-digit performance improvement overall.) As I see it, Javascript will always be much slower than other languages for complex data structures because everything is stored on the heap. [1] https://github.com/josephg/chipmunk-js https://github.com/josephg/chipmunk-js [2] https://github.com/josephg/Chipmunk-js/blob/ec447072458f40093c62c5cbfb71f8ca4f58975e/lib/cpArbiter.js#L361-L419 https://github.com/josephg/Chipmunk-js/blob/ec447072458f4009...
- modeless 4y ago
  10 years ago was around the time asm.js was just getting started, and that's what drove a lot of these optimizations. I think V8 is a lot more clever now. And the other browsers have largely caught up as well (or even surpassed V8 in some cases). And you can now safely ignore IE :)
  - josephg 4y ago
    I hear what you're saying, but my intuition disagrees with you. Asmjs was optimized in browsers when I did that test. I think people tend to overestimate how much subsequent versions of V8 improve performance in niche areas like TypedArrays. Especially now that V8 is very mature. I suspects if I re-ran that test, performance would have improved across the board but I'd get the same relative performance result with TypedArray code. It would be fascinating to try though. I wish I kept the code.
    - modeless 4y ago
      I think typed arrays are not a niche area anymore. They were 10 years ago, but today they are very widely used.

josephg 4y ago

About a decade ago I hand-ported the chipmunk2d physics engine to javascript. After porting it, I tried about 30 different things trying to make the code run faster. Some things I tried made it faster. Some made it slower. The most performance-critical section is the "arbiter applyImpulse" physics code[2], which is all math. I tried putting everything in as big TypedArray to avoid all the object lookups, but performance got slightly worse, not better. I still have no idea why. I think the reason is that the optimizer couldn't optimize the typedarray lookups at the time. Not in the same way it can optimize math on normal objects. Maybe v8 is more clever now? I dunno! The biggest performance win I got was from inlining vector fields. Chipmunk heavily uses {x,y} 2d vectors. Lots of objects looked like this: {pos: {x, y}, velocity: {x, y}, ...}. Flattening everything to this {posx, posy, velocityx, velocityy, ...} made the code uglier. But it caused a massive performance improvement because it reduced the number of objects allocated on the heap. (This one change reduced the number of heap allocations by about 70% from memory, and it caused a double-digit performance improvement overall.) As I see it, Javascript will always be much slower than other languages for complex data structures because everything is stored on the heap. [1] https://github.com/josephg/chipmunk-js https://github.com/josephg/chipmunk-js [2] https://github.com/josephg/Chipmunk-js/blob/ec447072458f40093c62c5cbfb71f8ca4f58975e/lib/cpArbiter.js#L361-L419 https://github.com/josephg/Chipmunk-js/blob/ec447072458f4009...

modeless 4y ago
10 years ago was around the time asm.js was just getting started, and that's what drove a lot of these optimizations. I think V8 is a lot more clever now. And the other browsers have largely caught up as well (or even surpassed V8 in some cases). And you can now safely ignore IE :)
- josephg 4y ago
  I hear what you're saying, but my intuition disagrees with you. Asmjs was optimized in browsers when I did that test. I think people tend to overestimate how much subsequent versions of V8 improve performance in niche areas like TypedArrays. Especially now that V8 is very mature. I suspects if I re-ran that test, performance would have improved across the board but I'd get the same relative performance result with TypedArray code. It would be fascinating to try though. I wish I kept the code.
  - modeless 4y ago
    I think typed arrays are not a niche area anymore. They were 10 years ago, but today they are very widely used.