Introduction to Data-Oriented Design [pdf]

My experience with ECS is that you shouldn't use an "ECS system". You should just do ECS. Have an array of all your particles and then update all the positions according to the velocities. Don't use a framework where you do something like get_all_entities_with<Particle, Position, Velocity>(). Just have struct particles {vector<vec3> positions, velocities;}. Well, managing those parallel arrays gets pretty annoying, but you solve that with a parallel-array class template rather than a whole framework that promises to do everything. (You might not actually need parallel arrays anyway - AoS might work just fine here because you usually touch each field of each particle once per frame and exactly in order.)

> ECS

“Entity Component System”, for those like me who didn’t immediately think of it.

This is basically how I've always designed things, and I really feel like it's the best approach. Pick the right way to model data, and the algorithms will flow naturally from it. The cognitive load of reading "data" code rather than "algorithm" code is a lot lower in my opinion; reading through a bunch of declarative types like struct definitions isn't nearly as much work as reading through functions that operate on them, and moreover, it's a lot easier to spot any potential bugs in them because you don't need to maintain very much "state" in order to understand them. Maybe this is why I've generally found ECS conceptually pretty easy to wrap my head around (which is of course separate from whether it's easy to use or not, as that depends a lot more on both what the framework exposes and how a team chooses to use it).

While the idea is itself not without merit the problem is when people design these data oriented systems without abstractions and in fact it's often difficult to find good abstractions around the data the problem comes when the system, the data and functionality needs to change. There will be problems.

So while it's great to think about the data flow it's also important to think about the abstractions around it,.ie the (system) interfaces that let the system evolve without having to propagate changes everywhere while reaping the benefits of data orientation.

I feel like DoD is one of those things that only makes sense after you already believe in it. There's a sort of KISS epiphany that you have to go through which I don't think the commonly available info on DoD helps you to reach. It doesn't help that everything about it tends to get hung up on overly-specific C++ optimization advice.

> You are working for Mike Acton.

AI generated skill?

Note: AFAIU "Data Oriented Programming" (as championed e.g. in the Clojure community) and "Data Oriented Design" (as championed in the video game community) are very different philosophies for different use-cases and diametrically opposed on many dimensions. People knowing only the one phrase and assuming both to be synonymous will be in for a lot of confusion when reading about the other.

> convert tables to lists

array languages give you concepts for thinking about these problems where you can succinctly express that entire talk in a single sentence, something like "inverted tables improve cache locality and optimize for time and space, prefer them where it matters". yes, got it, also a well known conclusion in array world.

a table is a 2 dimensional data that stores your records row by row and the items of a column all have the same data type. the way an array of structs would. an inverted table is a list of original table's columns. like a struct of arrays.

so if you have a table,

     x
  ┌────┬──────┬─┬─────────┐
  │mob1│level1│0│0.0243902│
  ├────┼──────┼─┼─────────┤
  │mob2│level2│1│0.0147059│
  ├────┼──────┼─┼─────────┤
  │mob3│level2│0│0.0120482│
  └────┴──────┴─┴─────────┘

there's an idiom for converting it to an inverted table

     ]y=:(<@(>"1)@|:)x
  ┌────┬──────┬─────┬─────────────────────────────┐
  │mob1│level1│0 1 0│0.0243902 0.0147059 0.0120482│
  │mob2│level2│     │                             │
  │mob3│level2│     │                             │
  └────┴──────┴─────┴─────────────────────────────┘

you can then splice it across variables,

     'name level isactive v'=:y
     isactive
  0 1 0

so you have converted a table to lists.

DoD may be a good idea for a business context where one of your main priorities is getting the most efficient use out of memory bandwidth & cache.

E.g. if your job is writing game engines or middleware used by AAA games with fancy graphics to run on consumer hardware, getting the most efficient use out of the players' limited memory bandwidth may be very important.

For many (most?) arbitrary commercial software projects in other contexts, performance isn't high priority & memory bandwidth isn't a bottleneck. Performance just has to be 'good enough' & 'good enough' performance may be easily attained by writing typical OO code that uses cache & memory very inefficiently - so in those cases DoD is an engineering trade off that solves a problem that doesn't need to be solved & may create new problems if introduced.

Based on your description the only prescriptive thing one can say is lean into composition and avoid inheritance. While there are some pitfalls with composition it is easier to unpack and restructure than inheritance is. Changing requirements will of course incur changing data structures etc. but hopefully this can be avoided a bit by using LUT/indexes and other things to minimize impact.

Why do you lowercase "oriented" when "DOD" (and "OOD") is the usage in the slides?

One good example of DoD which isn't CPU-cache-related is relational databases. When designing a CRUD application, the Data-Oriented way of doing it is to figure out what data you will be storing and how to organize that data to minimize access times, which is what you're doing when you design the DB schema.

An example of failing to follow DoD is the N+1 query problem: a programmer builds an abstraction that operates on individual DB rows, but "where there's one, there's more than one": you will inevitably be running that code in a loop so that you can process multiple rows. If instead the programmer had abstracted over groups of rows, then per-item query overheads suddenly become per-batch overheads.

I consider it generally the ideology of anti-OOP. While OOP ideology teaches you to structure the program after the problem it solves, DOD ideology explicitly teaches you to throw all that away and think about what runs fastest on the computer. Maybe it should be called Computer-Oriented Programming or Hardware-Oriented Programming. The specifics very a lot but the top-level ideology of "fuck OOP" is consistent.

People posted a wide variety of specific ideas under my other comment: https://news.ycombinator.com/item?id=49061421

> cache-aware data structures and algorithms

Maybe hardware- and access-aware more generally.

One of Mike Acton's other talks has a "Is Data-Oriented Design even a thing?" section, which goes over what he means when he refers to DOD:

https://www.youtube.com/watch?v=rX0ItVEVjHc&t=741s

I actually see ECS as a subset of the relational data model. It's effectively binary relations, in database / E.F. Codd terms.

When you look at it from that angle, rather than as an optimization technique, it makes it clear there is actually an elegant programming model here.

Unfortunately game engine programmers tend to think databases are super uncool and not relevant. They could actually learn a lot.

"flecs" pulls in some concepts from the relational algebraic world in that it has some sense of joins, etc. but it's a bit ad hoc.

The ultimate "data oriented design" game engine could be a high speed, GPU/SIMD accelerated, in-memory Datalog engine. And then the game world expressed in Horn clauses and logic.

https://github.com/timbran-project/mica is some of my playing in this area.

I think this is broadly true, but there's also a subset of DOD design advice (e.g. see Richard Fabian's book) that has a lot to say about relational database design. In our team it's provided us with some very practical motivation for more normalised table designs. Doing 1+n requests to the database due to poor implementation feels similar now to pointer chasing.

The connection is that ORMs convince you to have an object-oriented view of the world, which maps nicely to object classes. But highly normalised designs don't map as cleanly to classes and objects, so you need to approach with a different style of programming on the application side.

Instead of seeing a User instance, you start to see a more complex bundle of login methods, profile events, etc.

I knew OOP had failed when we started getting programmers who solved memory issues with batching instead of thinking about why they were loading that much data into the memory to begin with. For the previous 20-30 years that didn't really matter. Code was the bottleneck and implicity and abstractions helped developers ship changes faster. It turned out that it didn't give us maintainable or safe code bases, and there is a sweet irony to be found in the world of banking. Where the JAVA systems meant to replace the old parallel paradigms are now being replaced with systems that are better links between the COBOL systems and the customers than JAVA ever was.

AI changes that. Especially because it appears that LLM's can't understand the OOP abstractions any better than your hardware can compute it.

That being said. OOP and DOD both have advantages and disadvantages. If you go back to what I said first it wasn't exactly a failing of the OOP paradigm. The biggest issue I have with OOP is actually that it's too easy to do things wrong with it. Which isn't helped by the multimillion dollar industry which thrives on teaching developers everything except core computer science. People know their DRY, SOLID, CLEAN, TDD, Agile and every design pattern in the world, but they don't know how the interface they've just implemented actually handles their data.

Have a look at the talk Practical Data-Oriented Design by Andrew Kelly [1]. He covers the following techniques:

1. Indexes instead of pointers. This allows you to avoid alignment of 8 bytes in your structure for x86_64.

2. Storing booleans out-of-band. Booleans cause padding all the time.

3. Struct of Arrays. Based on your question I assume you're familiar with it.

4. Store sparse data in hash maps. I remember one time when it allowed to eliminate inheritance.

5. Encoding the data instead of OOP/polymorphism. I haven't got an occasion to use it. The idea is to add extra tags to avoid boolean properties.

[1] - https://vimeo.com/649009599

- Data-Oriented Design Revisited: Type Safety in the Zig Compiler - Matthew Lugg - https://youtu.be/KOZcJwGdQok?si=YDal2Gwb0IJPFgrI

- Andrew Kelley Practical Data Oriented Design (DoD) - https://youtu.be/IroPQ150F6c?si=F1Z0pLO2W5hbQgpM

- CppCon 2014: Mike Acton "Data-Oriented Design and C++" - https://youtu.be/rX0ItVEVjHc?si=jv4hhTSBh3XH--xQ

- Why You Shouldn’t Forget to Optimize the Data Layout - https://cedardb.com/blog/optimizing_data_layouts/

- Handles are the better pointers - https://floooh.github.io/2018/06/17/handles-vs-pointers.html

- Enum of Arrays - https://tigerbeetle.com/blog/2024-12-19-enum-of-arrays/

- Data oriented design book - https://www.dataorienteddesign.com/dodbook/

- Data-oriented design in practice - Stoyan Nikolov - https://youtu.be/_N5-JjogNXU?si=vhaxYcfE6tl11Sux

- Programming without Pointers - Andrew Kelley - https://www.hytradboi.com/2025/05c72e39-c07e-41bc-ac40-85e83...

- More Speed & Simplicity: Practical Data-Oriented Design in C++ - Vittorio Romeo - CppCon 2025 - https://youtu.be/SzjJfKHygaQ?si=jafavSl2YJWk4vIx

- Rust Handle - https://taintedcoders.com/rust/handles

Yes. Array programming happens to overlap heavily with DOD in modern hardware because of caching and SIMD, but if you were programming an Atari ST it wouldn't.

There are also cases where the optimal data format isn't array oriented because the memory access patterns for the problem in question just require something else.

You also have to think of hot vs cold data, which has nothing to do with arrays.

A lot of it just comes down to KISS and avoiding unnecessary overhead and indirection (like vtables, C++ STL containers etc.) so you're getting the most out of the hardware.

It means instead of building a street object, with car objects that have tire objects as its children and then running through the tree to rotate the wheels you just have an array pointing to exactly the appropriate data type to accomodate the type of wheel rotation you need.

Very often the answer is indeed arrays, but it can easily be something else, depending on the problem. Data driven design is not very complicated, it just means instead of thinking about abstraction you think about the shape the data needs to be in to accommodate the most common transformations you need to do with it.

Yes