Does the execution process of this function involve searching? Suppose there’s an entity with a unique component data in the world. In the Update function of a system, if I use SystemAPI.GetSingleton to retrieve this component data, does it affect efficiency? I remember that in traditional OOP methods, using something like GameObject.Find can be resource-intensive. My understanding of the underlying implementation of ECS is not comprehensive; I’m just drawing some associations.
Additionally, are there any specific considerations to keep in mind when programming with ECS, especially in terms of efficiency and safety? Are there any summarized technical documents or resources that focus on these aspects?
Burst compiled version will cost about 0. Non-burst compiled - approximately 0.
Its very fast because its based on queries. Think of it as a dictionary lookup.
Difference in design also matters. You’re not going to use GetSingleton per each entity (or at least, shouldn’t).
Rather per system. It drastically reduces overhead as well.
Biggest issue that might be is multithreading & dependencies. Generally you don’t want to read or write on the main thread anything. But if nothing writes to that specific component - no jobs are scheduled against it - no forced job completion. Then again, GetSingleton[RW] does not do any automatic dependency management as it should. So it doesn’t really force anything.
In any case, you can always fetch data via ComponentLookup / BufferLookup if you grab Entity via GetSingletonEntity instead of data directly. This way you’ll also offload work to the job while keeping proper dependencies. But, that won’t work with system singletons & other hacky component “collections”.
Tl;DR:
Take a peek at profiler from time to time, or just Systems window.
If you see something costs way too much - that’s the time to jump to the profiler and see what systems & jobs take too much of it.
Best documentation when it comes to Entities is the code itself.
2 Likes