Why do we need [UpdateInGroup], [UpdateBefore], [UpdateAfte and input/output dependencies?

Not important, but I am curious: Why do we need both? Shouldn’t the input and output dependencies already define everything required - or if we define an attribute, shouldn’t that essentially be equal to using the input/output dependencies?

What if those two contradict, which one will actually win?
What if attributes and/or dependencies contradict each other?

[UpdateInGroup], [UpdateBefore], [UpdateAfter] only define the order the systems run, not the order jobs are scheduled executed unless you enable simple dependency mode.

2 Likes

D’oh. Yes. Obvious. Thanks anyway.

I made a graphic for this a while ago for the importance of read/write but it also includes difference with simple dependency

People tend to assume simple dependency mode is just how dependencies work (where system order is order of dependency)

5 Likes

What’s the difference in what you call default and simple? (from code perspective)

Adding ENABLE_SIMPLE_SYSTEM_DEPENDENCIES will enable simple dependency mode. It’ll just create a dependency chain on order of systems rather than read/write. Reduces the cost of calculating dependency chains at the cost of having less efficient job scheduling.

It’s not advised to use but there are certain projects especially on mobile with small entity counts and not great thread utilization that can benefit from it. From using it ages ago, I found the biggest issues is you really have to remove all system groups as they trigger sync points.

2 Likes

Just small clarification as I think precise namings important in this case, this is exactly order of jobs scheduling to local queue (or forcing them to be available for worker threads if use ScheduleBatchedJobs) AND systems run. But what you meant in diagrams is jobs execution which order depends on unity dependency resolver and not on these attributes :slight_smile:

2 Likes

Yes that is an important clarification, I will edit

2 Likes