nancygold's Journal

Efficiency concerns of ECS
It may appear that using ECS for very fine grained objects, like individual particles and voxels, can be less efficient than a structs. Or if we can use ECS for say 8bit microcontroller. After all, a uniform ECS component asks for some form of a sparse vector, like say an open addressing hash table, which includes both entity id and optional component value.

Yet we forget that we have full control over entity id ranges layout. For example, we can allocate ids between 0 and N to be particles. Given that we don't even need a component table. The particle system just goes from 0 to N, updating the particles x,y,z. And allocating an entity itself is as easy as incrementing and index. Additionally, if ids are inside specific ranges, their lists can be further compressed. I.e. if we have 16 players, we need 4 bits to reference a player in your `owned_by` component.

Now separate voxels are usually highly compressed as an octree, which has local attribute tables, similar to component tables. So we need a different system to process them and query their X,Y,Z coords. But again, as long as we don't access the entity's fields directly, we don't have any efficiency issues. Otherwise we indeed have to do

is_voxel(id) ? get_voxel_xyz(id) : get_sparse_xyz(id)

And lets be honest, properly coded octree has nothing in common with OOP, since it is processed in a similar fashion to ECS systems (it is expensive to do single voxel operations on octrees, but cheap to do say erase half of its voxels). I think one can implement an octree, albeit not super efficiently, using a pure ECS system, with the reserving id ranges method. Although we can encounter id shortage quickly due to the massive amount of ids the voxel models can consume. At least with 32bit ids.

Furthermore, on a 8bit systems (i.e. NES's 6502), we have 256 byte segments, so we can't just store a linear list of objects. The system itself invites us splitting our object across multiple segments. Maybe that is the reason inexperienced people managed to implement complex game logic in 6502 assembly, but struggle to do that with C++/Java/C#/Rust after reading all these Uncle Bob's clean code books?

TLDR: stay away from OOP, if you want efficient software that can run fast even on NES.

Current Mood: contemplative
Current Music: Christopher Stone & Bruce Langhorne - The Fourth Wise Man