Comment by Altern4tiveAcc
3 hours ago
> SoA is weak if you are adding/removing monsters more often than accessing a single "hot" field.
Why is that? Genuinely curious. Does "weak" mean that it performs worse than AoS, or that the gains aren't as significant versus AoS?
It's because removing a monster with 20 fields from an SoA structure means resizing 20 arrays. Removing the same monster from an AoS array involves resizing a single array, which you're going to process in a very cache friendly way.
I'm not sure why anybody would at the same time be implementing SoA AND resizing 20 arrays for a single delete, those things seem to be on either ends of the "I care about performance" spectrum.
Assuming ordering isn't a concern, can't you just have a field called "removed" and skip those when iterating?
Or swap it with the last monster, and keeping an index for the last monster alive.
Then you have to read the "removed" field on every field read on every operation.
SoA is only useful when you don't read multiple fields for most operations.
Presumably they're referring to resizing the arrays.
Array resizing is avoidable with an embedded free list if ordering is of no concern.