0
\$\begingroup\$

I have been working with an ECS for my current game and I noticed that I came up with quite a few systems that go over lists of entities that sometimes overlap, so it's not unlikely that I loop on the same entity more than once as more than one system is processing that same entity.

Wouldn'it it be better to just iterate once over all th entities that should be updated instead? And if so, how would you do that? Redesign the systems so that a single system is in charge of more stuff on the same entities? Move the code from systems to an update() method on the components? Or am I just worrying about something that isn't really going to have a big impact on performances compared to other bottlenecks that could arise from taking a different approach?

Improve this question
\$\endgroup\$
2
  • 2
    \$\begingroup\$ "Wouldn't it be better to just iterate once over all the entities that should be updated...?" Not necessarily. By doing all of one type of calculation at a time you make good use of the instruction cache, and in some cases can take advantage of data parallelism/SIMD or other batch-processing efficiencies that are harder to achieve if you're bouncing between different behaviours constantly. It's not guaranteed faster or slower, so profiling is the best way to know for sure in your case. \$\endgroup\$
    – DMGregory ♦
    Jan 1, 2016 at 14:15
  • 2
    \$\begingroup\$ Even so, the flexibility of an ECS may well be worth it to you even if it is slower. In any case, what you're doing is creating a problem in your head where none may exist in the real world. DMGregory is correct that profiling is the only way to know, and profiling on a variety of your lowest common denominator target machines is the only way to know if your end users will experience a problem. \$\endgroup\$
    – Patrick Hughes
    Jan 2, 2016 at 6:57

1 Answer 1

Reset to default
1
\$\begingroup\$

It may appear inefficient on the surface but the reason that subsets of entities are iterated in this fashion is to make use of caching mechanics which could actually yield faster results than if you attempted some other alternative.

I also find it important that having separate behaviors split into their own systems and managing their own list of entities allows those systems to change over time with minimal impact to other behaviors. Despite the performance concerns, it does make replacing or changing a system much easier and all the while adheres to Single Responsibility Principle and Separation of Concerns.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .