RepairPathSystem Performance/Profiling Improvement

General
1

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):

bad-profile
bad-profile1801×587 155 KB

My Fix (force AIMovementSystemGroup last):

good-profile
good-profile1671×598 151 KB

2 Likes
2

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

3

Good investigation!

I think this is not necessarily an improvement, though. It depends on what other jobs will be running. So I’m hesitant to include it in the main package.

4

Ya, I don’t think it actually improves much in Astar itself, it just ensures that developers don’t have to change update order of custom systems to get more accurate profiling of them. I have seen a couple of threads about WaitForJobGroupId and Idle which might be caused by a similar situation.

Since only some devs are using Systems and Jobs, it might be enough to just add some documentation for best practices when using them with Astar.