# Component arrays vs. entity structs? [closed]

Two of the main systems I've seen in entity system tutorials are:

• An Entities class with one array / [hash]map for each component, with indices corresponding to entity IDs.
• A list of Entity structs, which have the components as fields, and possibly a pointer to a "cold" struct for less used components.

What are the reasons I would use the former over the latter, considering that the latter seems much easier to implement? Is there some advantage to having each attribute laid out contiguously in memory?

## closed as too broad by Lars Viklund, Vaillancourt♦, Josh♦Jan 19 '16 at 16:41

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

Is there some advantage to having each attribute laid out contiguously in memory?

It's better for cache locality of data access. Memory access is slowest part of all modern computing systems. As memory buses pull in multiple bytes in "cachelines" and most modern CPUs will prefetch memory that it detects are being accessed contiguously, keeping data that is used sequentially laid out in memory contiguously can have a signficant ans positive impact on efficiency.

That said, performance fetishism is not as useful as one might think, even in games. Plenty of big AAA games use something closer to the other technique you mention. There are places where cache locality of data is super important and places where it has little meaningful impact. Sometimes, ease of implementation or ease of maintenance will be more important than raw performance. A particle system is a place where every little bit of performance matters, for example, but an entity or component that only exists on a few dozen actors doesn't need to be maximally efficient.

A component-based architecture can use some ES-like techniques (a System that operates on contiguously-allocated data associated with Entity ids) for some components and can use a simpler container of objects for other components. There's no reason that one has to shoehorn oneself into the ES pattern for everything. A well-designed simple component architecture lets you use the appropriate design methodology for each component.

• @Nik-Lz: I didn't say a dozen entities, I said a type of component that only exists on a dozen entities. An entity might indeed just be an actor (not necessarily all actors are like creatures though!) but that's irrelevant since those are made-up terms and mean different things in every engine; a number of engines indeed say Actor when they mean GameObject/Entity/Sprite/etc.. :) I'm not sure an example of code would help this answer any, and the question is closed regardless so putting effort into improving the answer seems unuseful. :) – Sean Middleditch Sep 13 '18 at 5:28