RepairPathSystem Performance/Profiling Improvement

When I was profiling I noticed that JobRepairPath was causing my systems to wait because they were competing for threads (especially under pressure). After playing around with update order I realized that JobRepairPath can run after SimulationSystemGroup (during Vsync). Which is great, but it only does so if nothing else is waiting for threads to use.

My fix was to force the AIMovementSystemGroup to update last inside the SimulationSystemGroup to ensure that JobRepairPath doesn’t clog up the threads for other systems.

	//Added to ensure threads aren't clogged by RepairPathSystem
	[UpdateInGroup(typeof(SimulationSystemGroup), OrderLast = true)]
	[UpdateAfter(typeof(TransformSystemGroup))]
	public partial class AIMovementSystemGroup : ComponentSystemGroup {

Im not sure if it is actually changing much in terms of performance, but its definitely reducing the time it takes to complete the SimulationSystemGroup in the profiler when under pressure, and gives more accurate profiling of my systems since they aren’t stuck waiting. A better fix might be to separate the RepairPathSystem into it’s own group and for it to be forced last so that developers can run systems after pathfinding, but never after the RepairPathSystem.

Original (with some systems updated after RepairPathSystem):

My Fix (force AIMovementSystemGroup last):

2 Likes

Love this write up, thanks a lot for contributing it. Tagging @aron_granberg so he gets a look at this.