Unity DOTS / ECS (Entity Component System) Data-Oriented Memory Architecture: Advanced Implementation and Real-World Architecture

[Dylan Gray]

I’m currently re-architecting a high-frequency simulation system (60Hz authoring, targeting 1ms solve budget on Ryzen 7 7800X3D) and hitting real cache-thrashing walls between systems. My current split is chunk-based Archetype, but I’m seeing L2 misses spike during inter-system transfers. For those deep in the SoA weeds: how are you structuring component data to keep hot paths within a single cache line (64B) while avoiding false sharing between parallel jobs? Do you pad Stride manually or rely on Burst’s alignment hints, and at what cost to memory bandwidth?

On the Burst/SIMD side, I’m noticing diminishing returns past float4 vectorization on my dot-product-heavy math. Are people manually tuning vectorization factors per SystemBase, or is Burst’s auto-parallelization just doing the heavy lifting? And critically — what benchmark methodology are you trusting? I’ve been using Unity’s DOTS Performance Test Framework, but I want real per-core cycle counts (perf/VTune) rather than wall-clock numbers that hide thread-scheduling noise. Anyone got reproducible profiling pipelines that separate compute-bound from memory-bound systems?

🎮 Battlestation & Rig: Ryzen 5 7600X | RTX 4070 Super Dual | 32GB DDR5 6000 CL30 | FormD T1 SFF | AOC AGON Pro AG276QZD 240Hz QHD OLED | Custom Tofu60 Lubed Gateron Oil Kings + Lamzu Maya 4K + Artisan Hien Mid | Beyerdynamic DT 990 Pro (250 Ohm) + FiiO K5 Pro ESS DAC

📍 Toronto, ON (Canada)

"Chasing the silicon lottery one megahertz at a time."

[Noah Cox]

Great topic to dig into. The core mental shift with DOTS is understanding that you’re not just “using jobs”—you’re fundamentally redesigning how data lives in memory. The default chunk size of 128KB with the Archetype system means all entities sharing the same component layout get packed contiguously, which is what actually unlocks cache-line efficiency. When you’re iterating 100k entities through a Job, you want contiguous SoA (Structure of Arrays) layout rather than random access into scattered structs. The classic mistake I see devs making is writing ECS code that still does pointer-chasing—accessing components by entity ID or doing random index lookups inside the job, which completely defeats the cache-coherency win. If your SystemV is spending more time waiting on memory loads than compute, you’ve broken the data-oriented contract.

On the implementation side, couple Burst with the Job System and stop writing manual memory management where you don’t need it—the NativeArray and Chunk APIs handle a lot. But be careful with IComponentData vs IStructuralData: adding/removing components triggers archetype transitions and can cause heap allocations or chunk splits, so bulk-ops and EntityManager batch calls matter a lot in hot paths. For anything with real streaming or physics-scale entity counts, also look at how ParallelFor scheduling interacts with your job’s data dependencies—overlapping compute across cores is where you actually see the perf gains, but you need proper IJobChunk patterns with WithAll/WithAny filters to keep the archetype grouping tight. And don’t sleep on the DOTS Physics or Entities Graphics packages if you’re pushing large-scale sims; hand-rolling a naive job loop for thousands of colliders will get smoked by their optimized spatial partitioning

"Faceit Level 10 (2420 ELO) | CS2 Competitive • EU North"

[Brandon Peterson]

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!"

[Dylan Gray]

Followed the advice, the framedrops basically stopped after reworking my systems to use SoS chunk layout instead of those pointer-chasing AoS structs — cache thrashing was absolutely killing me. Switched to NativeArrays with contiguous component data, stopped allocating on the main thread, and finally got the Burst compiler to actually parallelize my jobs properly. Huge improvement, thanks guys!

[Author]

Posts