Unity DOTS / ECS (Entity Component System) Data-Oriented Memory Architecture: Competitive Benchmark Analysis and Залізо Interactions

[Carter Peterson]

I’ve been benchmarking DOTS/ECS workloads across my 3600X and 5800X3D to see where the data-oriented actually pays off in real-time simulation, and I’m hitting some confusing wall. When I switch a chunk of entities from AoS to pure SoA layout, my cache line occupancy looks cleaner on paper, but I’m seeing inconsistent frame times in the 1-100 percentile even after Burst SIMD optimization kicks in. My question is: how are you all handling the StrideOfGroup and chunk boundary alignment when mixing systems, and does anyone have empirical data on whether SoA layouts actually reduce cache misses on Zen architecture, or if the prefetcher fights you on large entity counts?

Also curious about the hardware scaling story here—am I chasing the wrong metric? I’ve been measuring frametime consistency and peak FPS, but I wonder if the burst compiler’s vectorization is being bottlenecked by memory bandwidth rather than compute on my current rig. Anyone running headless multi-threaded batch benchmarks to isolate the ECS throughput from rendering overhead, and what’s your recommended methodology for capturing stable frametime data without the measurement itself skewing the numbers?

🎮 Battlestation & Rig: i5-13600K | RTX 4070 Super | 32GB DDR5 6000 CL32 | DeepCool LT720 | AOC AGON Pro AG276QZD 240Hz QHD OLED | Logitech G Cloud + Razer DeathAdder V3 Pro + Endgame Gear EM-C Pad | Beyerdynamic DT 990 Pro (250 Ohm) + FiiO K5 Pro ESS DAC

📍 Munich (Germany)

"Direct drive torque changes how you feel every curb and apex."

[Dylan Bell]

The core win with DOTS is that you’re killing the AoS cache-thrash problem that kills single-threaded perf in traditional Unity. When you store components in a Struct-of-Arrays layout inside fixed-size chunks (default 2048 entities, so ~40KB per chunk at 20-byte components — fitting inside L2 comfortably), you get contiguous memory access instead of chasing scattered pointers through the heap. For a benchmark, this shows up as dramatically better cache-line utilization: a 64-byte x86 cache line gets fully consumed instead of wasting space on padding scattered across a 128-byte-aligned struct. If you’re profiling this, watch your L2/L3 hit rate in VTune or perf stat — the whole point of archetype chunking is keeping your hot loop inside L1/L2 so you’re not bottlenecked on the memory wall.

The moment you jump to a component outside the current chunk, that’s a cache miss penalty of ~1?

🎮 Battlestation & Rig: Ryzen 5 7600X | RTX 4070 Super Dual | 32GB DDR5 6000 CL30 | FormD T1 SFF | AOC AGON Pro AG276QZD 240Hz QHD OLED | Razer Huntsman V3 Pro TKL + Razer Viper V3 Pro + Pulsar Superglide Glasspad | Sennheiser HD 560S Open-Back + Creative Sound BlasterX G6 DAC

📍 Melbourne (Australia)

"Rapid trigger active, zero deadzone; never miss a counter-strafe."

[Marcus King]

Great topic. The thing most people get wrong about DOTS is assuming the perf win comes from the ECS API itself — it actually comes from the memory layout, and that’s where your benchmarks will live or die. When you switch from a component-per-class AoS approach to a pure SoA (Array of Structures) layout via NativeArray and Chunk storage, you’re fundamentally chasing cache line hits. A cache line is 64 bytes, and

"i5-13600K | RX 7800 XT | Thermalright Peerless Assassin 120"

[James Brooks]

The thing most people miss when benchmarking DOTS is that the archetype layout’s real win isn’t raw speed—it’s cache-line utilization. With Structure-of-Arrays storage, a system that only reads Position and Velocity loads exactly those components, so you’re not wasting 64-byte cache lines on irrelevant

"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"

"Veni, vidi, vici." • Кіберспорт & PC gaming enthusiast"

[Emma Brown]

Great topic, and I think the benchmark needs to separate two things that usually get conflated: raw compute throughput vs. memory-bound throughput. With DOTS, the real win almost never comes from the math being faster—it comes from the cache. When you convert a traditional ECS to a Structure-of-Arrays layout, you’re really trying to hit the 64-byte cache line with a single load instead of straddling it. If your System processes, say, 1024 entities but only touches the Position and Velocity components, you want those packed contiguously so a single cache line pulls in multiple entities’ worth of data. I saw a 3-4x jump in throughput just

[Author]

Posts