Andrew Kelley: A Practical Guide to Applying Data Oriented Design (DoD)

- Data-Oriented Design Revisited: Type Safety in the Zig Compiler - Matthew Lugg - link - Andrew Kelley Practical Data Oriented Design (DoD) - ▶ this video - CppCon 2014: Mike Acton "Data-Oriented Design and C++" - link - Why You Shouldn’t Forget to Optimize the Data Layout - link - Handles are the better pointers - link - Enum of Arrays - link - Data oriented design book - link - Data-oriented design in practice - Stoyan Nikolov - link - Programming without Pointers - Andrew Kelley - link - More Speed & Simplicity: Practical Data-Oriented Design in C++ - Vittorio Romeo - CppCon 2025 - link - Rust Handle - link

A good introduction to SoA (for anyone curious) are the two most famous Data-Oriented Design talks by Mike Acton (game engine dev) [1] and Andrew Kelley (Zig lead dev) [2] respectively. I read a book book about DoD [3] really which confused me at first with all its talk about database table design (in a book about a high-performance C++ game engine?), but when it finally clicked it was amazing. The point is that you want to think hard about your access patterns and what could constitute good "primary keys", then model it accordingly. SoA ends up being useful a lot of the time, because having your data in homogeneous arrays/vectors is great for cache locality and branch elimination. Even without SIMD you can get huge speedups from that, but that's also where your compiler (or you as a programmer) can get incredible SIMD gains. SoA is not a silver bullet as it may not align well with your access patterns, but it can great to add to your toolkit. --- Mike Acton: Data-Oriented Design and C++ : link Andrew Kelley: A Practical Guide to Applying Data Oriented Design : ▶ this video Richard Fabian: Data-Oriented Design : link

I think I had a pretty good understanding of set theory through programming, and although I tried to get into the more mathematical side of it, I found most things to be 1. trivial (because I was used to thinking in lists, sets, hashmaps, etc.), or 2. irrelevant to me. The latter was a shame, because I've always liked the abstraction of math, but I couldn't help but feel I wasn't learning anything actionable when learning more about sets (though maybe I'm wrong). What had a big impact on me was the relational model, specifically after reading Richard Fabian's Data-oriented Design book [1]. I had watched Mike Acton's famous Data-oriented Design talk [2], then Andrew Kelley's talk [3] where he explains speedups in the Zig compiler using DoD principles (largely using methods from Acton's talk), but Fabian's book tied these concepts to database normalization and the relational model. Most DoD advice is very "exercise left to the reader", because it's about matching a specific problem, but using the relational model and considering your data's primary and foreign key relations can be really powerful. I just wish more of that power was exposed through regular programming language interfaces, rather than having to pull in and marshal data through a DB. I might have to try C# and Linq. 1. link 2. link 3. ▶ this video

SoA is nothing new. Not sure why it needs to be even discussed... Anyway, here's few videos of interest: link ▶ this video Odin also supports SoA natively link

Good write up, I like where you're going with this. Your article reads like a recent graduate who's full of excitement and passion for the wonderful world of programming, and just coming into the real world for the first time. For Go, I wouldn't say that the choice to avoid generics was either intentional or minimalist by nature. From what I recall, they were just struggling for a long time with a difficult decision, which trade-offs to make. And I think they were just hoping that, given enough time, the community could perhaps come up with a new, innovative solution that resolves them gracefully. And I think after a decade they just kind of settled on a solution, as the clock was ticking. I could be wrong. For Rust, I would strongly disagree on two points. First, lifetimes are in fact what tripped me up the most, and many others, famously including Brian Kernighan, who literally wrote the book on C. Second, Rust isn't novel in combining many other ideas into the language. Lots of languages do that, like C#. But I do recall thinking that Rust had some odd name choices for some features it adopted. And, not being a C++ person myself, it has solutions to many problems I never wrestled with, known by name to C++ devs but foreign to me. For Zig's manual memory management, you say: > this is a design choice very much related to the choice to exclude OOP features. Maybe, but I think it's more based on Andrew's need for Data-Oriented Design when designing high performance applicatio

TL;DR: I'm trying to Forth a Lisp. This is long winded, but maybe you have some thoughts here. I've been building a DOM-builder API recently in Rust. The existing options (there are many) tend to use textual templating, which can't reason well about anything, or basic macros, which never support indentation. I wanted something that was just code, where I'd be in full control on the indentation (or lack thereof) programmatically. The closest equivalent is Python's Dominate [1], though its indentation mechanisms are buggy. So I built a system using the traditional tree where Nodes own other Nodes at random addresses, and I built a renderer that renders those nodes and concatenates their strings recursively. It ended up working but it was hacky and very slow for the large inputs. In release mode, it was taking almost a minute to render 70 files, and I want about two orders of magnitude lower. I ran it through profilers and optimized it a bit, but wanted to see if I could simplify the architecture and reduce the amount of work the computer could do. I read about flattening ASTs [2] and how through optimizing that format, you can end up with a sort of bytecode [3]. I also looked into Data-Oriented Design, watching Mike Acton's famous talk [4], Andrew Kelley's talk about DoD in Zig [5], and reading through the DoD book by Richard Fabian [6]. I ended up with something that works quite well for traversing and rendering, which is a stack that can be traversed and rendered in O(n), but

I recently spent a week or so creating a library for my project. There's not a lot of code, but it was hard to reason about the data model, what I wanted the API to look like, and what I wanted actually rendered on the other side. I was proud after getting it working, but when I had to run dozens of files through it, it was horribly slow. I don't tend to write a lot of hot code, so I was excited by the fact I had to profile it and make it efficient. I decided that I should rewrite the system, as my mental model had improved and the code was doing a lot more than it should be doing for no reason. I've spent the last few days redesigning it according to Data-Oriented Design. I'm trying to get the wall-clock time down by more than an order of magnitude. I'm not sure how it's going to turn out, wish me luck :) Since I mentioned DoD, these three links will probably come up in conversation: Mike Acton's famous performance talk: link DoD in the Zig compiler: ▶ this video The DoD book: link

This reminds of an amazing talk by Mike Acton on Data oriented design: link And there is a related talk by Andrew Kelley implementing these ideas on Zig toolchain: ▶ this video

That talk is great, but I remember some discussion later about Go actually NOT using this technique because of goroutine scheduling overhead and/or inefficient memory allocation patterns? The best discussion I could find is [1]. Another great talk about making efficient lexers and parsers is Andrew Kelley's "Practical Data Oriented Design" [2]. Summary: "it explains various strategies one can use to reduce memory footprint of programs while also making the program cache friendly which increase throughput". -- 1: link 2: ▶ this video

The talk I am referring to is from 2024 and shows some metrics improving by 30% or more. And Andrew said that's not yet shipped: ▶ this video So, are you sure about that?? EDIT: ok, the talk was uploaded just last week, but someone in the comments clarified that: > The original talk is from 2021.. Thank you for reuploading. I feel stupid now :/