Unity DOTS vs GameObjects: 2026 Performance Benchmark Results

Unity DOTS isn’t automatically faster than GameObjects. Its advantage appears when many similar entities perform the same CPU-heavy work and their data can stay in stable, cache-friendly layouts.

A reported 2026 bullet-workload test reached approximately 10,000 entities at 60 FPS with DOTS, compared with about 6,000 using a MonoBehaviour baseline. That’s roughly 1.67 times the capacity, but it describes one workload—not a universal conversion rate for Unity projects.

Key takeaways

• DOTS is strongest with repetitive, data-heavy CPU work such as projectiles, crowds, targeting, and server simulation.
• The relevant comparison is often Burst and Jobs plus ECS storage versus an ordinary MonoBehaviour design—not ECS versus a carefully optimized manager loop.
• Benchmark the project you plan to ship, using the same rendering, physics, hardware, package versions, and frame-time targets.

Unity DOTS vs GameObjects: cache efficiency and data layout

A conventional GameObject update might look like this:

foreach (var bullet in bullets)
{
    bullet.transform.position += bullet.velocity * deltaTime;
}

That loop can be perfectly adequate. A well-designed manager can cache references, keep bullets in a flat collection, and update them with one loop rather than relying on thousands of individual Update callbacks.

The typical MonoBehaviour architecture, however, often stores the required data across several objects. A position may live in a Transform, velocity in a component, and gameplay state in another managed object. The collection itself may be contiguous while the values the CPU needs are scattered elsewhere. The processor follows references, fetches cache lines containing unrelated data, and waits for additional memory loads.

Entities groups objects with the same component composition into an archetype. Archetype data is stored in chunks, with each component type arranged in a packed array. Unity documents ECS chunks as nominally 16 KiB blocks. That is not 16 KiB of usable component payload in every case: headers, entity counts, alignment, component layout, and the number and size of components all affect capacity.

The same movement system can therefore operate more like this:

[BurstCompile]
public partial struct MoveBulletJob : IJobEntity
{
    public float DeltaTime;

    public void Execute(ref LocalTransform transform,
                        in BulletVelocity velocity)
    {
        transform.Position += velocity.Value * DeltaTime;
    }
}

The generated query walks matching component data in chunk order. It doesn’t need to locate a separate object for every bullet, and the loop is a good candidate for Burst optimization.

A simplified comparison looks like this:

GameObject manager:
    for i = 0 .. bullets.Count:
        bullet = bullets[i]
        bullet.position += bullet.velocity * dt

ECS IJobEntity:
    for each matching chunk:
        for i = 0 .. chunk.entityCount:
            position[i] += velocity[i] * dt

The difference is not that one loop has fewer lines. An optimized GameObject manager may already use a single loop. The architectural distinction is where the data lives, how predictable the access pattern is, and whether the hot loop can be compiled and scheduled efficiently.

Modern CPUs fetch memory in cache lines, commonly modeled as 64 bytes on desktop hardware. An ECS system that reads only position and velocity can make much better use of each fetched line than a system that follows references through objects containing unrelated fields. Still, there is no universal “ECS is 10 times more cache efficient” figure. The result depends on component size, query selectivity, access order, CPU model, and the system being measured.

What the 2026 benchmark actually shows

The often-cited 2026 comparison was an independently published 2D bullet test that ran entity counts from 100 to 20,000 and reported 30 trials per condition. Its approximate 60-FPS thresholds were:

Relative capacity: 10,000 ÷ 6,000 = 1.67×

That’s a useful result for a projectile simulation. It doesn’t establish how 10,000 animated characters, physics bodies, or networked objects will perform.

The available report also doesn’t isolate every source of the improvement. DOTS may have benefited from packed component storage, Burst compilation, parallel Jobs, fewer managed allocations, and fewer per-object callbacks at the same time. The GameObject version may have used a conventional MonoBehaviour baseline rather than a pooled, manager-driven loop.

A more informative test matrix would include:

That distinction matters in production. If a manager loop with cached data reaches nearly the same frame time as ECS, migration may not repay its conversion and tooling costs. If the manager stalls while a Burst job scales cleanly, ECS has a stronger case.

Burst, Jobs, and structural-change costs

Burst is a performance layer, not a guarantee. It compiles compatible C# to optimized native code and may use SIMD instructions such as SSE, AVX, AVX2, or Arm Neon. Straight-line arithmetic over packed component arrays is a strong candidate. Branch-heavy code, random access, managed references, unsupported Unity APIs, and aliasing can limit the result.

The Job System helps when work is independent and batches are large enough to offset scheduling overhead. Parallelism won’t fix poor locality or excessive synchronization. A small job with random entity lookups can lose to a simple single-threaded loop.

Structural changes are another common source of surprises. Adding or removing components can move entities between archetypes, alter query membership, and force synchronization. Unity’s documentation has published a one-million-entity comparison involving enableable components and EntityManager operations:

These are documentation measurements, not generally reproducible frame-time guarantees. Hardware, Unity version, Entities version, component layout, and surrounding work all affect the result. Their practical value is showing the relative cost of different operations.

Enableable components can change an entity’s active state without moving it between archetypes. Pooling, command batching, stable archetypes, and deferred structural changes can likewise prevent spikes during gameplay.

How to benchmark a real project

Use a player build and record the full test environment:

• Unity, Entities, and Burst versions;
• CPU model and operating system;
• graphics API, resolution, VSync, and render pipeline;
• entity count and component layout;
• job batch size and worker-thread settings;
• physics, animation, and rendering configuration.

Measure frame time rather than relying on average FPS. Track simulation, rendering, physics, main-thread, worker-thread, garbage collection, and frame-time percentiles separately. If possible, collect cache misses, branch misses, instructions per cycle, and entities processed per millisecond with tools such as Intel VTune, Linux perf, or the profiling tools supplied by the target mobile platform.

Run at least two configurations: a minimal-rendering or headless test for simulation cost, and the actual camera, materials, animation, and physics setup. Otherwise, a GPU bottleneck can hide a large CPU difference.

A 2025 Unity forum report described roughly 2,500 ECS physics cubes at about 1,500 FPS on PC versus approximately 550 FPS for GameObjects. The same discussion reported around 23 FPS for 1,250 GameObjects and about 3 FPS for ECS on an Android setup. Those figures are anecdotal rather than controlled benchmark results; the post’s hardware, Unity and Entities versions, physics configuration, and rendering conditions make direct reproduction uncertain. They’re useful mainly as a warning that DOTS performance can change dramatically across platforms and implementations.

There is no magic entity count at which ECS becomes worthwhile. Ask instead:

1. Is the frame CPU-bound?
2. Do many entities perform similar work?
3. Do systems touch a small, predictable component set?
4. Can entities remain in stable archetypes?
5. Can the hot path compile under Burst?
6. Can the work run independently across threads?

If most answers are yes, prototype the bottleneck in ECS. If rendering, animation, GPU particles, or physics already dominates the frame, changing gameplay storage may not improve the shipped result.

A hybrid architecture is often the sensible endpoint. ECS can own projectiles, crowds, targeting, movement, or server simulation while GameObjects handle cameras, UI, authoring, bespoke animation, and a limited number of visible objects. Synchronize at deliberate boundaries instead of converting every value every frame.

Frequently asked questions

Does Burst make Unity ECS faster than GameObjects?

Often, but not automatically. Burst can turn a compact, compatible loop into efficient native and SIMD code. Compare ECS without Burst, Burst single-threaded, and Burst with parallel Jobs to see where the improvement comes from.

How many Unity entities can maintain 60 FPS?

There is no universal limit. The reported 2026 bullet test reached approximately 10,000 DOTS entities and 6,000 MonoBehaviour entities at 60 FPS. Physics, rendering, component size, CPU hardware, and system complexity can move those thresholds substantially.

Should I migrate an entire Unity project to ECS?

Usually not as a first step. Profile the project, identify the CPU-heavy system, and prototype only that workload. A hybrid design often captures the practical benefit without replacing UI, cameras, authoring workflows, animation, and low-count gameplay objects.