🧠 Lesson 3.1: Data-Oriented Thinking

The Memory Gap

Here is a fact that reshapes how you write performance-critical code: a modern CPU can perform an arithmetic operation in well under a nanosecond, but fetching a value from main memory (RAM) takes on the order of 100 nanoseconds. That's a factor of a hundred or more. The processor doesn't sit idle politely — it stalls, waiting for data to arrive, doing nothing useful for hundreds of cycles.

This is the memory gap, and it has been widening for decades: compute got fast far quicker than memory got close. The practical consequence is blunt — in most game code the CPU spends more time waiting for data than computing on it. If you want speed, the winning move is rarely "do less math." It's "wait for memory less often."

💡 The reframing. Object-oriented design optimises for how humans organise concepts. Data-oriented design optimises for how the hardware reads memory. They frequently disagree, and on the hot path the hardware wins.

Cache Lines & Misses

To hide the memory gap, CPUs keep small, fast caches (L1/L2/L3) between the core and RAM. When you read one byte, the CPU doesn't fetch just that byte — it pulls in the whole cache line around it, typically 64 bytes, on the bet that you'll want the neighbours next. If your next read is already in cache, that's a cache hit (a few cycles). If it isn't, that's a cache miss (the ~100 ns stall).

So performance hinges on a simple question: is the data I need next sitting right beside the data I'm using now? Walk an array front to back and the answer is yes on almost every step — the CPU even prefetches ahead, so the data is waiting before you ask. Chase pointers to objects scattered across the heap and the answer is no, every step is a fresh miss.

AoS vs SoA

Say you have 10,000 entities and each frame you only need to advance their positions by their velocities. The natural OOP layout is an Array of Structs — one array, each element a fat struct holding everything about the entity:

// Array of Structs (AoS) — everything about an entity together
struct EntityAoS
{
    public Vector3 position;   // 12 bytes  ← the only fields our loop needs
    public Vector3 velocity;   // 12 bytes  ←
    public Quaternion rotation;// 16 bytes
    public float health;       // 4 bytes
    public int teamId;         // 4 bytes
    public FancyStats stats;   // ...more cold data...
}

EntityAoS[] entities;   // 10,000 fat structs, back to back

void MovePositions(float dt)
{
    for (int i = 0; i < entities.Length; i++)
        entities[i].position += entities[i].velocity * dt;
}

The loop only touches position and velocity — 24 useful bytes — but each struct might be 64+ bytes. So every cache line the CPU loads is mostly the fields you're ignoring (rotation, health, stats). You pay full memory bandwidth to drag along cold data you never read. The cache is full of garbage.

The data-oriented layout is a Struct of Arrays — split each field into its own packed array:

// Struct of Arrays (SoA) — one packed array per field
Vector3[] positions;   // 10,000 positions, back to back
Vector3[] velocities;  // 10,000 velocities, back to back
Quaternion[] rotations;
float[] healths;
// ...

void MovePositions(float dt)
{
    for (int i = 0; i < positions.Length; i++)
        positions[i] += velocities[i] * dt;   // both arrays stream cleanly
}

Now the two arrays the loop touches are each fully packed. Every cache line is 100% useful data; the prefetcher streams both arrays perfectly; nothing cold is dragged along. Same result, a fraction of the memory traffic — often several times faster, with no change to the arithmetic at all.

Hot & Cold Data

The AoS problem has a name: mixing hot data (fields touched every frame — position, velocity) with cold data (fields touched rarely — the display name, the loot table, a reference to a UI panel). When they share a struct, reading the hot field always pays to load the cold ones too.

The fix is to separate them by access frequency. Keep the per-frame hot fields in their own tight arrays; push the rarely-touched cold fields elsewhere. SoA does this naturally, but the principle applies even in ordinary OOP code: a component that runs every frame should not carry a 200-byte payload it reads once at spawn.

Where This Leads: The DOTS Stack

Everything in the next two modules is machinery for making SoA, hot/cold-split data easy and safe to process at scale. Unity's Data-Oriented Technology Stack is three packages that build on each other:

Figure 2: The stack. Each layer assumes cache-friendly data underneath it — which is why this mindset comes first.

The rest of Module 3 gives you the two workhorses: the Job System (Lessons 3.2–3.4) to spread that array-processing across CPU cores safely, and Burst (Lesson 3.4) to compile it into vectorised native code. Module 4 then wraps all of it in ECS. But every one of those tools is only as fast as the data layout you feed it — garbage in, cache misses out.

A First Taste: Unity.Mathematics

One concrete tool you'll use constantly is the Unity.Mathematics package — a math library designed for this world. Its types (float3, float4, quaternion, float4x4) are lowercase, blittable value types the Burst compiler can turn into SIMD instructions, and its functions live in a static math class that reads like a shader:

using Unity.Mathematics;   // note: float3, not Vector3

float3 position = new float3(2f, 0f, 5f);
float3 velocity = new float3(1f, 0f, 0f);
float dt = 0.016f;

position += velocity * dt;                 // component-wise, like Vector3
float dist = math.distance(position, float3.zero);
float3 dir  = math.normalize(velocity);
quaternion rot = quaternion.RotateY(math.radians(90f));

You can convert freely with Vector3 (float3 p = transform.position; just works), but inside jobs and ECS you'll use the Unity.Mathematics types because Burst optimises them aggressively. Think of float3 as "Vector3 that a compiler can vectorise."

🔎 You've already seen it. The real 25,600-entity render in Lesson 4.1 positioned every cube with a float3 and a Unity.Transforms.LocalTransform. That was data-oriented layout in action — packed component arrays processed in bulk.

Hands-on Challenge

Summary

🚀 What's Next?

You now have data laid out for the hardware. In Lesson 3.2: Your First Job — IJob & Scheduling we take that packed data and process it on Unity's worker threads with the C# Job System, turning a serial loop into safe multithreaded work.