No history yet

Data Oriented Shift

From Objects to Data

In traditional Unity development, everything revolves around GameObjects and MonoBehaviours. This object-oriented approach is intuitive: a car object has a 'Car' script with data (speed, color) and logic (drive, brake) all in one place. It's a great way to model the world, but it has a hidden performance cost that becomes clear when you want to scale to thousands of active elements.

The problem isn't the logic itself, but how the data is stored in memory. Your computer's processor doesn't fetch data from its main memory (RAM) one byte at a time. It has a small, incredibly fast memory buffer called the CPU cache right next to it. When the CPU needs data from a specific memory address, it grabs not just that byte, but a whole chunk of adjacent memory, known as a cache line. The CPU is betting that you'll need the nearby data next. When it guesses right, it's called a cache hit, and everything is fast. When it guesses wrong—a cache miss—it has to go all the way back to RAM, which is comparatively slow. It's like a chef having all their ingredients prepped and laid out on the counter (a cache hit) versus having to run to the pantry for each item (a cache miss).

Traditional GameObjects are stored all over the place in memory. The 'Car' object might be here, the 'Tree' object over there, and another 'Car' somewhere else entirely. When a system needs to update the position of all cars, the CPU jumps around in memory, leading to constant cache misses. This random memory access is a major bottleneck.

The ECS Architecture

Data-Oriented Design (DOD) flips the script. Instead of organizing code around objects, it organizes data for the hardware. The primary implementation of this in Unity is the Entity-Component-System (ECS) architecture. It separates the 'what' from the 'how' and the 'data' from the 'logic'.

An Entity is just an ID. Think of it as a number, not an object. It's a lightweight tag that identifies a 'thing' in your world, like 'Car #42'.

A Component is pure data. It contains no logic or methods. A Position component holds X, Y, Z coordinates. A Velocity component holds a vector. Crucially, in DOTS, components are typically [{}] (structs in C#), not Reference Types (classes). This keeps them compact and directly stored in memory blocks.

A System contains all the logic. A MovementSystem finds all entities that have both a Position and a Velocity component and updates their positions. It doesn't care if the entity is a car, a bullet, or a bird; it only cares about the data it needs to operate on.

This separation is key. Instead of one script handling everything for a car, you have multiple, focused systems operating on streams of component data. This allows for massive parallelism and avoids the memory-hopping that plagues the object-oriented model.

Memory Layout is Everything

So how does ECS solve the cache miss problem? Through a clever memory management system built on Archetypes and Chunks.

An Archetype is a unique combination of component types. For example, an entity with Position, Rotation, and Velocity components has a specific archetype. An entity with just Position and Rotation has a different one. The ECS framework automatically groups all entities with the same archetype together.

These groups of entities are then stored in Chunks, which are 16KB blocks of memory. Inside a chunk, the data is not stored entity by entity. Instead, it's stored component by component. All the Position components are laid out in a contiguous array, followed by all the Rotation components, and so on.

When the MovementSystem runs, it asks for chunks containing the Position and Velocity archetype. The CPU can then load an entire array of Position data into its cache, process it at lightning speed, and then do the same for the Velocity data. There are very few cache misses. This linear memory access is the foundation of DOTS's performance and allows for incredible scaling.

Quiz Questions 1/6

What is the primary performance bottleneck in traditional, object-oriented Unity development when scaling to thousands of active elements?

Quiz Questions 2/6

In the context of CPU performance, what is a "cache hit"?

This shift in thinking—from individual objects to managed streams of data—is the key to unlocking the performance needed for the next generation of games. It requires you to think less about object behaviors and more about data layouts, but the payoff is the ability to create worlds with a scale and complexity that were previously out of reach.