Introduction to Data-Oriented Design: Shifting Focus for Performance

Introduction to Data-Oriented Design [pdf]

I explain how shifting focus from objects to data flow dramatically improves performance by optimizing memory access. Traditional Object-Oriented Design often causes cache misses, while Data-Oriented Design organizes data for linear processing. This approach simplifies multithreading and enables better utilization of co-processors like GPUs by isolating data from code.

It's about shifting focus to how data is read and written.
  1. dustbunny

    The real key pillar to this world view is putting the data first in your design of the algorithm.

    So if your working on a physics engine and your optimizing collision detection, you think about the data in -> data out of the problem you are solving as the primary driver of how the code should be written.

    You start with defining the data, and build from there.

    Different types of applications all have different shapes of data so would have differently shaped optimal code. Eg) a physics engine would use some kind of spatial hash thing which can be optimized differently based on if stuff can be added/removed while it's running. A 3d renderer operates on big buffers of matrices and vertex data. A game is usually composed of some long lived things and a lot of short lived things.

    The key message in Mike Acton's talk was:

    "If you have different data, you have a different problem."

    While ECS systems are not a panacea that solves all problems in a perfect data oriented way, they are generally more malleable than Object Oriented hierarchies. This means it's generally more feasible to write "near optimal" code in an ECS framework than in a mature Object Oriented code base.

    But the key message isn't "use X framework", it's "start by defining the data".

  2. HexDecOctBin

    Mike Acton (author of this presentation) has released a LLM skill for Data Oriented Programming: https://github.com/macton/nagent/blob/main/context/data-orie...

  3. ghosty141

    I personally love the idea of DoD but from my experience it rarely works well in practice since one of the key assumptions of understanding ur problem is often not given as new requirements pop up and change all the time.

    At work we are rewriting and reengineering system from scratch and its crazy because the limitations of the old system are now gone we get the most insane feature requests that are even accepted by the team lead et al. This makes such an approach impossible since DoD is exactly the opposite of flexible design in my opinion.

    Im curious has anybody really followed this in a big long living commercial project?

  4. PessimalDecimal

    This seems like a particular branding on cache-aware data structures and algorithms. Is there more to it?

  5. inigyou

    Serious question. Does DOD mean anything more than array programming, in practice?

More from this day

2026-07-26