My problems with JS:
1. Allocating objects or closures results in death by garbage collection.
2. So I spend tons of effort managing indices, juggling reused objects, and passing them around awkwardly because functions can only return 1 value.
3. As for the objects, only TypedArrays/ArrayBuffers are fast, but they too require juggling due to having fixed maximum lengths.
If I started using Rust or something instead, would it ease these specific problems? Or is this just my life now?
@jonikorpi some useful resources I liked when setting mine up:
- https://moonside.games/posts/archetypal-ecs-considered-harmful/
- https://www.remedygames.com/article/how-northlight-makes-alan-wake-2-shine
- https://www.gdcvault.com/play/1024001/-Overwatch-Gameplay-Architecture-and
all of these use "sparse" ecs implementations, allowing ad-hoc adding/removing of components, which imo strikes a nice balance of developer friendliness for iteration and experimentation, while retaining most of the performance benefits of ECS (e.g. things are still packed into arrays, and most situations will experience good cache line utility)
@jonikorpi the alternate, is things like DOTs, which was cool! but requires a lot more ahead-of-time decl, which does benefit perf, but makes iteration a bit more cumbersome.
small example, this is the system that processes animations in my engine; by allowing adhoc adding of components to particular entities, I can easily add useful tag components. In this case, it's a "staged" animation, which is just a series of connected anims (a start anim, a loop/idle anim, and a completion anim).
@dotstdy @jonikorpi also, this haha
wasm is a bit of a pain, setting it up with SDL2/3 wasn't _too_ bad.
@jonikorpi Is it really a CPU bound Problem? From my personal experience most JS performance are caused by IO or initial bundle size.
Also most garbage collectors for JS are generational, which means they are fast for short-lived objects and the real problem are medium-duration objects, that fill up the old space. (I haven't measured it, so take with a grain of salt).
@Marthog Well all the code that I’m finding difficult/tiresome due to the above runs very often, or in large quantities.
Terrain generation and game logic in enormous bursts. Graphics and physics stuff 60–120 times per sec, audio synthesis 44000–96000 (aaagh) times per sec.
That’s a lot of CPU! And much of it suffers from any kind of GC hitches.
@jonikorpi those specific problems, yes - massive bottleneck for JS performance
new problems: understand & working with Rust's ownership and borrowing
learning new language: something like Odin/Zig allows low level alloc/dealloc, pointers etc
halfway option is to offload any compute heavy tasks to Wasm with shared array buffers. Zig compiles super easy to Wasm. Workers allow concurrency.
@jonikorpi my life now as well. 😌
My assumption would be similar problems, but better tooling, in Rust (etc) …but I haven’t worked a lot with these languages either.
Maybe there are coding patterns and/or tooling that would help in JS? I’ve been finding the flyweight pattern helpful — some CPU overhead but not the memory/GC issues. Recent example:
Description Highlights Adds performance- and memory-oriented APIs for working efficiently with large vector collections: BufferPrimitive BufferPoint BufferPolyline BufferPolygon BufferPrimitive...
@jonikorpi yes, because Rust actually has a notion of "place in memory", you can be very explicit about where allocations happen, and many things that can only be solved by boxing allocation in JS can be done with by-value or by-reference.
Whatever you do, test performance only in a release build though xD
Joni Korpi
superfunc
Josh Simmons
Gunnar
David Bushell 🪿
Lesley Lai
Don McCurdy
Leonardo Giovanni Scur