I remember when that first did the rounds a few years ago... The thing is, while it's interesting seeing the potential trouble spots Acton highlighted, he didn

I remember when that first did the rounds a few years ago... The thing is, while it's interesting seeing the potential trouble spots Acton highlighted, he didn't actually show a better way of doing any of it. As someone who has also done his fair share of low-level/high-performance programming in C++, I would take some convincing that the result isn't going to be somewhat faster but effectively write-only code. That might be OK if you know your target platforms well enough to count on those micro-optimisations not being premature and you know no-one is going to care about maintaining your code for very long, which is not entirely unrealistic in the games industry but doesn't apply to much else. However, I think a lot of the ideas on those "slides" go beyond Data Oriented Design as the term has come to be used, and into general low-level, architecture-specific optimisations. There's nothing wrong with exploring the latter, of course, but I'm not sure it's helpful to conflate very fine-grained, platform-specific, relatively localised adjustments with a high-level view of how to group multiple properties on a set of objects in memory, or with the more general principle of transforming your data in advance into some format that lends itself to the kind of processing you want to do. (None of which is to say that articles on how to do that sort of low-level optimisation on popular platforms wouldn't be interesting. I'm just suggesting that they would probably have to go some way beyond what is commonly called DOD today before they were likely to get interesting.)