Barrier system performance

I'm finding this is quite expensive and wondering if this is intended or I'm using it wrong.

I'm creating around 100 entities per frame with a single component outside of any systems. That works great. Using a barrier system to get a command buffer within a job and issue a destroy request triggers the update on the main thread but it doesn't look right. First it's chewing up over 5ms of cpu time. Second it's all from WaitForJobGroupID (under my barrier system name in the profiler). Is it actually forcing the job itself to run on the main thread?

 

FYI I'm not seeing this behavior of high cpu usage in another system using a very similar pattern with the same number of requests and entity destructions. The difference there is I'm using ComponentSystem and using PostUpdateCommands instead of JobComponentSystem and barriers.

 

WaitForJobGroupID is not the real running time of your Barrier system and can be deceptive I think.. I means your barrier system waits for the job to complete (in threads) before it can execute commands. It happens when the best schedule plan is to wait for the job with nothing else to do at that moment. (I have had a lot of WaitForJobGroupID when I was putting UpdateBefore/After unnecessarily too tight)

ComponentSystem + PostUpdateCommand of course does not cause WaitForJobGroupID since it runs sequentially on the main thread.

 

Actually I'm seeing ComponentSystem wait on job group even without any post update commands. I'm updating component values in OnUpdate in a loop.

So this system, system A was put first in the player loop order, and the other systems that actually run jobs were put last. System A is reporting 1ms - 2ms wait for job group time while the actual amount of work it's doing should be like 1/4 of a ms or so.

The 1ms to 2ms it's reporting as waiting for job group corresponds almost exactly to the total time spent by jobs that the other systems are starting.

So it looks very much like the jobs don't even start until system A runs, which is then forced to wait for them to complete. Doesn't make sense how that could happen but it kind of fits actual behavior.

 

This is what the entity debugger shows FYI. CombatEntitySystem is the system in question. The last two are running a couple of jobs. I did find it interesting where EndFrameBarrier got placed, it's being used by the last two systems.

 

Ok so the entity debugger isn't showing systems in the actual order they are run (why not?), so now the behavior makes sense. CombatEntitySystem is running immediately after the systems that start jobs.

 

Yeah, this trick got me also. At first I thought it was ordered by the running order, but later of I figured out it is just sorted alphabetically which is disappointing. I hope they add an option to order by execution order later on.