ABSTRACT
Common programming wisdom used to encourage delaying optimizations until later in the project, and then optimizing only those parts that were obvious bottlenecks in the profiler. That approach worked well with glaring inefficiencies, like particularly slow algorithms or code that is called many times per frame. In a time when CPU clock cycles were a good indication of performance, that was a good approach to follow. Things have changed a lot in today’s hardware, and we have all experienced the situation where, after fixing the obvious culprits, no single function stands out in the profiler but performance remains subpar. Dataoriented design helps address this problem by architecting the game with memory accesses and parallelization from the beginning.
