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

What Hacker News said

Recommends emmanueloga_ · 2024-11 · on “Rust for tokenising and parsing”

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]

Recommends iamcreasy · 2025-07 · on “Writing memory efficient C structs”

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]

Recommends Rendello · 2025-10 · on “Your data model is your destiny”

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

Recommends gethly · 2026-01 · on “Why Object of Arrays beat interleaved arrays: a JavaScript performance issue”

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]

Recommends Rendello · 2026-07 · on “Everyone Should Know SIMD”

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 with

Cites brabel · 2024-07 · on “Aro – Zig's new C compiler”

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 :/

Cites Rendello · 2025-10 · on “Forth: The programming language that writes itself”

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 string

Cites publicdebates · 2025-12 · on “Thoughts on Go vs. Rust vs. Zig”

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