[Blog post] Why and when you should use SoA

[Alex Parrill via Digitalmars-d-announce]

On Sunday, 27 March 2016 at 00:42:07 UTC, maik klein wrote:
>> I think SoA can be faster if you are commonly iterating over a 
>> section of a dataset, but I don't think that's a common 
>> occurrence.
>
> This happens in games very often when you use inheritance, your 
> objects just will grow really big the more functionality you 
> add.
>
> Like for example you just want to move all objects based on 
> velocity, so you just care about Position, Velocity. You don't 
> have to load anything else into memory.
>
> An entity component system really is just SoA at its core.

You can't have a struct-of-arrays with polymorphic data like game 
objects; the individual objects would have different properties 
and methods.

If you use a Unity-esque component system, you could potentially 
pool each object's component into an array... but then whatever 
component updates you're running likely touch most of the object 
state anyway (ex. the hypothetical PositionComponent would be 
updating both its position and velocity).

Also I forgot to mention: Your "Isn’t SoA premature 
optimization?" section is a textbook YAGNI violation. I might 
have to refactor my web app to support running across multiple 
servers and internationalization when it becomes the Next Big 
Thing, but it more than likely will not become the Next Big 
Thing, so it's not productive for me to add additional complexity 
to "make sure my code scales" (and yes, SoA does add complexity, 
even if you hide it with templates and methods).

Since AoS vs SoA is highly dependent on usage, I'd like to see 
some performance metrics with real-world access patterns instead 
of benchmarks that unrealistically only look at part of the data 
at a time, or use structs that are too small to matter. Of 
course, actually getting those metrics is the hard part...