Is it good practice to carefully consider the number of ComponentSystems and JobComponentSystems

It is a common occurrence for developers to see WaitForJobGroupId in the profiler when running a JobComponentSystem-heavy game. This is usually worth it though since they also end up seeing a lot of blue in the worker threads. However, sometimes the worker threads are overburdened while the main thread has finished its job and is waiting for them to complete. This necessitates the need to offload work to the main thread.

Say my development process is to implement the physics and heavy lifting first. As a result nearly all the JobComponentSystems needed for the game are in place, and the profiler has a lot of blue in the worker threads and a lot of grey in the main thread. In this case would it be a good idea to code the rest of the non CPU-intensive game mechanics in ComponentSystems?

 

No.

If the jobs aren't being allocated when main thread is idle then that is a bug with the scheduler and you should post a reproducible bug report.

You should never use ComponentSystem over JobComponentSystem unless you have to do work that requires the main thread. Ideally you'd have 0 ComponentSystems in your application, though this is obviously not always feasible at least at the moment.

there was a post about this not long ago: https://forum.unity.com/threads/main-thread-underutilised-while-waiting-for-jobs-completion.691597/

where improvements are being made on this to fix edge cases where it's not happening as intended.

 

Ah I didn't explain it that well. My scenario is when there are so much work done in JobComponentSystems that even after the main thread has finished scheduling all the jobs, it still has to wait for them to complete.

 

I think your explanation was fine and tertle's response relevant. Read the linked thread or the thread linked at the end of the thread. It's the same issue isn't it? "main thread schedules lots of work then ends up waiting idle for it to complete, I'd like it to help in completing the scheduled jobs". Same as your situation isn't it?

 

Didn't see that link there. I'll browse it through. Thanks!

 

Yes if you follow the link I posted and go to the similar topic you'll see the result of improvements to the scheduler that are coming to reduce the main thread being idle.

Before
https://forum.unity.com/attachments/before-png.439649/

After
https://forum.unity.com/attachments/screenshot-2019-06-21-at-11-45-32-png.439652/

If after the update is available you still have similar issues, make another reproducible bug report because the intended behavior is work is scheduled on main thread if it's idle.

 

Ah, so the scheduler has improved to the point that it can schedule work to the main thread if all the other worker threads are busy and the main thread is idle?

 

As far as I'm aware, it's always been able to do it; it just didn't do it in certain cases.

 

According to https://docs.unity3d.com/Packages/com.unity.entities@0.0/manual/entity_iteration_foreach.html one must consider if "the amount of work the system performs is less than the small overhead of creating and scheduling a Job". Some of my systems activate only a few times per second to process a single entity each. Although you're right in accounting for future scalability, I'm certain that my system will never reach that level of scale (hundreds of entities dozens of times per second). What are your thoughts?

 

If it costs more to schedule the job than it does to do the work with burst, don't schedule the job. Only you can measure it to know what's appropriate though.