If I’m constantly using UpdateAfter and UpdateBefore on my many systems, and linking out output and input dependencies, would it be better performance and productivity wise to just define the orderings and dependencies in a few “aggregator” systems? What are the consequences of doing this?
#Should we be using fewer systems to schedule jobs rather than one system for every few jobs?
pallid portal
cobalt field
It seems it should be "mix of two". You should join as much as possible and on the other hand you should logically split the systems to still be readable and not use too much components at once.
In the past systems have more impact of performance, still does but ISystems should be quite efficient.
Before there was also a limitation for number of parameters in Entities.ForEach()
TL;DR you should aim for less systems (and jobs also) but don't be afraid of creating one if you need/want
you can always come back later and fix performance
vast folio
The unsatisfying answer is likely that It Depends ™️ .
The advantages of packing lots of jobs into a single system is a) less per-system overhead (not a huge issue unless you have 100s/1000s of systems), and b) finer-grained control over which jobs run in parallel with each other.
Component dependency tracking per system is done at a very coarse level; all jobs schedule by a system are combined into a single JobHandle, and that job handle is associated with all types accessed by the system. So, if SystemA schedules 10 jobs that write to 10 different components, and SystemB wants to schedule a job that reads from one of those components, the dependency system will conclude that SystemB's job will have to wait for all of SystemA's jobs to complete before it can run. If SystemB's job were moved into SystemA, it could set its input dependency to be the exact set of job handle(s) it actually relies on.
However, single systems are more difficult to profile and reason about; they show up as a single bar in the profiler by default, and a single entry in the Entities Systems window. But this is more of a tooling limitation than a runtime one. They also tend towards monolithic Do All The Things code blocks, if left unchecked.
Some early DOTS/ECS tutorials gave the impression that every data transformation should be its own job in its own system -- here's the system that only applies rotations, here's the system that only applies gravitational acceleration, etc. IMO that level of granularity is overkill.
pallid portal
Thank you for the detailed answer! I only have around 30 systems ATM, and probably 40 by the time of release. Nearly all use Bursted ISystem. I imagine that having granular systems won't be too much of a problem
vast folio
so TL,DR I'd probably lean towards combining related jobs into a single system as much as possible, especially if they're reading and writing the same components.
pallid portal
Ah, okay
vast folio
If you can identify "islands" of components and put all the jobs that process each island in a single system, that's probably a good happy medium. You have full control over running those jobs in parallel where possible, and can probably do a better job of that than the automatic dependency tracker.
pallid portal
Sure. The only issue is that the last time I tried this, I constantly ran into dependency errors. IT's very hard to track down which jobs can be run in parallel, at leas tin my project