4 ms·
> A problem there is that in memory the arrays are of course laid out one after the other, which actually destroys cache locality if you need to access more tha
by Firadeoclus 5y ago
> A problem there is that in memory the arrays are of course laid out one after the other, which actually destroys cache locality if you need to access more than 1 property inside a loop (it will need to load back and forth to the different property arrays), so it's a somewhat dumb approach.
Caches are perfectly capable of dealing with more than one stream of data (there are some very specific edge cases you may have to consider), accessing multiple arrays linearly in a loop is generally more efficient than accessing a single array of structs when you don't use almost all the struct elements.
- moldavi 5y agoI've seen a lot of ECS implementations that store components in hash maps, keyed by entity ID. They iterate over one hash map in a linear way which is fast, but then they do a bunch of slow lookups like GP is saying. In those situations, GP's suggestions are wise. If you can iterate over arrays in parallel like you say, that's also a good approach.
- ajuc 5y agoThere are tradeofs between regular arrays, sparse arrays and hash maps in ECS - it's very similar in concept to storage hints in relational databases, and similarly to relational databases you can add indexes if needed.
- professoretc 5y ago> They iterate over one hash map in a linear way which is fast, but then they do a bunch of slow lookups like GP is saying. Usually all but the most simple "systems" will need to access more than one component, which means you have a choice between a) store component data in regular arrays (and potentially waste huge amounts of space if relatively few entities have those components) or b) store component data in some kind of hash table (and then you use cache locality for all but the "primary" component of a system).