Profile First, Then Refactor: How a Unity RTS Developer Reports Tripling FPS in a Month

On 12 September 2025,

80.lv reported developer Alejandro Nunez's account of optimizing The Last General, his large-scale real-time strategy game. The headline figure is 3 times more FPS than before, achieved in a month. Treat that figure exactly as what it is: a developer self-report relayed by

80.lv. The source article publishes no frame-rate numbers, no test scene, no hardware specification, and no project code, so there is nothing here to independently reproduce, and this article invents none of those details.

What the source does give us is a usable method and a list of concrete changes, each of which can be checked against Unity's own documentation for plausibility. That distinction drives this whole article: the outcome number is unverified, but the techniques are real, documented Unity concepts, and the developer's reasoning about each one can be examined on its own merits.

Nunez's starting point was a profiler, not a rewrite. He used profiling to identify the worst issues and bottlenecks, and the reported result was reduced stress on both CPU and GPU. That order matters, and Unity's own DOTS guidance says the same thing in plainer terms: when developing with ECS-based code, keep the CPU Profiler open and read the console, because the profiler is what tells you whether a system you wrote might cause performance problems.

For ECS projects specifically, Unity documents two Entities Profiler modules: Entities Structural Changes, which shows when the framework creates or destroys entities and components, and Entities Memory, which shows per-frame archetype memory use. A structural change is expensive by design, because the framework moves an entity and a full copy of its data to a different archetype. Any RTS with thousands of entities being created, destroyed, or reconfigured at runtime should therefore expect structural churn to show up in a profile before it shows up anywhere else.

Nunez calls re-batching one of his greatest wins. Entities Graphics does not merge entities into the same batch if they were not instantiated at the same time, so entities that should render together can end up split across many small batches. His reported result was a batch reduction of about 90 percent, with large gains on CPU, because dispatching thousands of batches is costly, and on GPU, because there are far fewer commands to execute.

Unity's Entities Graphics documentation supports the underlying mechanism: it bakes authoring GameObjects into entities and creates BatchRendererGroup batches, each draw command rendering a group of instances that share the same mesh and material. Fewer batches therefore means less per-batch setup work on both sides of the CPU-GPU boundary. That is a documented property of the renderer, not a claim that depends on Nunez's numbers.

The fix itself has two forms, and the distinction is practical. Either instantiate all the entities at the same time, or reset the EntitiesGraphicsChunkInfo component of a group of entities to its default value, which makes Entities Graphics recalculate the batches for those entities. If you choose the second form, Nunez warns, you must do it for all the entities you want in the same batch within a single frame. His example is a system that grabs every asteroid that should share a batch and switches them all to default EntitiesGraphicsChunkInfo at once, then watches the batch count drop.

His verification advice is equally concrete: check with RenderDoc to see which objects are being placed in separate small batches for no reason, so you know which ones need the trick. That is a diagnostic step any reader can repeat in their own project, and it is the right antidote to applying the trick blindly: only re-batch the groups that RenderDoc actually shows as fragmented.

A second win was improving chunk occupancy close to 128 entities per chunk. In ECS, entities that share an archetype are stored together in 16 KiB chunks, and Unity's current Entities documentation states a maximum of 128 entities per chunk, with the actual capacity set by component sizes. A chunk that holds far fewer entities than its capacity wastes memory bandwidth on mostly empty storage, so occupancy is a real, measurable quantity, visible in Unity's Archetypes window alongside chunk capacity and unused space.

One technique Nunez used was splitting entities into a physics and logic entity and a separate rendering entity. Better occupancy was the direct benefit, but the split unlocked a second one: rendering for distant entities could be fully disabled while their colliders and other logic stayed active. That separation is the point worth copying, even for readers whose chunk counts differ: keep the data that must keep simulating apart from the data that only matters when it is visible.

A version note belongs here. Older Unity documentation examples compute chunk capacities above 128 for small archetypes, because the 128 cap arrived with newer Entities versions. Readers should therefore check the chunk capacity their own Entities version reports, rather than treating 128 as a universal constant across all versions. The developer's direction of travel, toward fuller chunks, survives that caveat; the exact ceiling depends on the version in use.

The remaining reported wins are about scheduling, not rendering. Nunez reordered systems, broke read and write dependencies between jobs and between systems, and unparallelized short jobs. Each of those is a recognizable ECS trade-off rather than a magic setting. A dependency chain forces work to wait; breaking it lets jobs overlap. But parallelizing a job that finishes almost immediately can cost more in scheduling overhead than it saves in execution time, so running short jobs on a single thread can be faster in practice.

Two more changes round out the list. World-space text GameObjects were replaced with Latios Calligraphics texts, removing GameObject-based text objects from a scene otherwise built on entities. And the number of child entities was reduced, which cut the time spent on the CalculateHierarchyLocalToWorld job, the work that recomputes world transforms down a hierarchy. Neither change is dramatic alone; together with the batching and chunk work, they remove per-frame overhead that scales with entity count, which is exactly the kind of cost that hurts an RTS most.

Finally, the source lists physics ideas in a weaker register, and this article keeps that register. Compounding static colliders and using the incremental static broadphase feature might help with performance, along with a grid-based sleeping system that turns objects static when nothing is moving in or around a specific cell. The source wording is might help, not did help, so readers should treat these as next experiments to profile, not as measured results from this case.

This article does not claim a verified 3 times frame-rate improvement, because no frame-rate numbers, hardware, test scene, or code were published in the source. It does not present any code, because the source publishes no project code to verify; the technique descriptions above are developer-reported steps checked against Unity documentation for plausibility, not code we executed. It does not claim the physics ideas as results, because the source itself presents them as possibilities. And it does not present any image as a gameplay screenshot or a profiling capture: all 8 images are self-made explanatory cards, labelled as such in every caption.