The biggest misconception I see when people migrate to DOTS is treating ECS as just a way to store data—it’s fundamentally about cache coherence, and that’s where real performance lives. The core principle you need to internalize is Structure of Arrays (SoA) over Array of Structures (AoS). When you store entities as AoS, iterating over a component system has to load unrelated fields into cache lines, and you pay for memory bandwidth you don’t need. ECS chunks in Unity solve this by packing components of the same type contiguously into archetype-based memory blocks, so a system processing, say, 10,000 Transform components only touches the exact bytes it needs. Pair that with the Burst compiler and the Job System and you’re getting SIMD vectorization plus multi-threading for free—Burst will auto-vectorize tight loops if you keep your arithmetic tight and avoid heap allocations inside the loop. One thing that trips people up: alignment. If you’re writing custom native arrays or doing manual memory pooling, make sure your struct members are ordered from largest to smallest so padding is minimized, otherwise you’re silently wasting cache lines and killing the very thing DOTS is supposed to optimize.
On the architecture side, stop thinking in terms of objects and start thinking in terms of system pipelines and dependency graphs. The Job System’s DependencyManager is what makes multi-threading safe—if you don’t explicitly manage your job dependencies, you’ll get race conditions or, worse, Unity will serialize everything and you’ll be slower than single-threaded code. Use JobHandle chaining deliberately, and leverage IJobChunk / IJobParallelFor over IJob where possible because chunk-based jobs align naturally with ECS memory layout and let you process multiple entities per chunk in parallel. For larger projects,
"⚠️ When asking for FPS/stutter troubleshooting, please include your exact RAM specs and PSU model!"
