Re:Build a simple 2D physics engine for JavaScript games (2012)
by mvladic on Wednesday August 24, 2022 @05:34AM
(#32576992)
Why would they use forEach? Is that criteria that your code is more modern? Or by forEach you mean: "for (const entity of entities) {...}"?
[ Parent
| on HN ]
Re:Build a simple 2D physics engine for JavaScript games (2012)
by samwillis on Wednesday August 24, 2022 @05:57AM
(#32577200)
forEach landed in Chrome in 2014 after this post, at the same time as for...of. True that forEach was available in some browsers earlier than that and could be polyfilled. Which do I mean? either.
Re:Build a simple 2D physics engine for JavaScript games (2012)
by jsgamedevthrow on Wednesday August 24, 2022 @08:38AM
(#32578606)
I have no idea what its like these days, but back then a ton of those sorts of methods would cause extra allocations (and thus unnecessary GC). That is the very last thing you want in a game engine.
Re:Build a simple 2D physics engine for JavaScript games (2012)
by fein on Wednesday August 24, 2022 @09:11AM
(#32578988)
You are correct. Everything that isn't a native for loop (forEach, map, reduce, etc) is slower than a native for loop.
https://leanylabs.com/blog/js-forEach-map-reduce-vs-for-for_...
Re:Build a simple 2D physics engine for JavaScript games (2012)
by dahart on Wednesday August 24, 2022 @10:31AM
(#32579951)
Looks like it’s gotten better recently with ratios like 1.5x - 3x; it wasn’t that long ago that using the functional iterators was 10x slower than imperative loops. Still, I have a hard time choosing the functional iterators even the cases that are only 50% slower, and even though I prefer them for how clean and elegant it makes the code. Performance and energy use matters, especially in a physics engine. Defaulting to the slower style might not be visible initially, but is sapping cycles from every corner of the code.