Eli5 How The Ecs Is More Performant Than It's Predecessor.

I've recently jumped into this new ECS world and I have to say I'm loving it, but I can't for the life of me understand how it's more performant.

I've always been one to keep as much logic away from the update call as possible, the thought of running huge amounts of code every single frame scares me. But with ECS we've got foreach loops coming out of our ears. I don't understand how looping so many objects multiple times every frame could possibly be more performant than just acting on something when called.

Fill me in! Also, why is there not an ECS specific sub-forum?

 

ECS Forums: https://forum.unity.com/forums/entity-component-system-and-c-job-system.147/

The really short answer is that the Job code you write in ECS get compiled and executed differently (Burst compiled) than other code you'd normally write in a MonoBehaviour. Although you can execute jobs in a MonoBehaviour, the ECS approach guides you more strongly toward that goal. The Burst compiled code runs much faster than normal C#, and the job itself automatically uses all available CPU cores.

 

Moved thread.

Because it's not a released feature yet. But getting there!

 

I see... you've given me some keywords to research, thank you! How exciting

 

ECS + C# Jobs + Burst are 3 different things that help each other in the new Data Oriented Tech Stack (DOTS)

- ECS : C# memory access was bad because OOP's "new" keyword put things wherever they want. In games we 50%+ do iteration on data, it is a major source of performance penalty when the iteration jumps everywhere along its path. We fix this by allocating an entirely new packed database (still on C# but using unsafe code) that's optimized for CPU to iterate on. If we do everything on this from now on then it's all free gain. No more `new` keyword, we now use ECS API to put things in and iterate on them. This database is very good at iteration in a way that CPU wants to work with. Also ECS provides mechanism so multithread code can work together on this 1 big database, and they properly wait for each other instead of hard crashing/introduce race condition. So not just fast for loops, but multiple parallel fast and safe for loops.
- C# Jobs : Unity already kick off several worker threads by default, that was mostly left idle other than processing your uGUI layout or your animation. With this you can now run custom code on them when they are not busy, so free performance. Normally you copy data to jobs and kick it off on worker thread, then collect answer. But with ECS together the jobs can access ECS db without copy + with auto dependency management. So this is even more free performance and more transparent job works.
- Burst : Compile job code to become better assembly. This is possible because DOTS put various restrictions that make it possible to guarantee some optimization (where general purpose compiler could not ever do, because it would break in some case where Unity patched it with harsh rules)