A* Pathfinding Project

Optimization tips for Work Items spikes?


#1

I’ve been using Astar for the past few years (pro version), and lately I’ve been doing a bunch of optimization the game I’m working on. The biggest issue that I’m running into with A* Pathfinding Project is that I’ll frequently get spikes in the profiler that look like this:

My game often features a large number of AI agents using Seeker.StartPath() on a 320x320 grid graph as much as 5 times per second each (they are required to repath often when following other AI agents). I’ve already gone through the optimization pages in the documentation, and unfortunately toying around with the settings on the AstarPath script hasn’t made a substantial difference.

I’m happy to provide as much information as you’d need to make a better diagnosis. At the moment I’m just not really certain as to what would be influencing these Work Items spikes, or what I should be looking into in order to reduce them.


#2

Hi

Those work item spikes come from graph updates, not from normal pathfinding. So what you should be looking at is how often you are updating the graphs and how large those updates are.
Also, make sure you are using a pretty recent version (4.2+) as that version contains some quite large performance improvements for updates on grid graphs.


#3

This makes sense, the graph needs to update whenever an object in the environment is destroyed, which occurs frequently.

I’ve tried a couple of methods for updating the graphs when an object is destroyed, and each produced similar results. The first is something like this:

Bounds bounds = GetComponent<Collider2D>().bounds;
AstarPath.active.UpdateGraphs(bounds);

For the second method, I use a GraphUpdateScene.Apply() after (I think) disabling the object’s collider.

In each case, the destruction of an object only modifies a few nodes, yet I still get a noticeable spike. Is there something I could be doing better here, or is a spike like this normal under these circumstances?


#4

Hi

Did you make sure you are using version 4.2+?

It doesn’t look like it’s just a few nodes. From the profiler screenshot it was over 1000 affected nodes.
Are you using a high erosion value perhaps? (a grid graph setting).


#5

I’m using the most recent version that’s available from the asset store, which I believe is 4.2.2.

I’ve been doing some more testing This is the spike that I get from using the following code:

Bounds bounds = GetComponent&lt;Collider2D&gt;().bounds; 
AstarPath.active.UpdateGraphs(bounds);

The collider seems to cover about 100 points, so that seems to be accurate. The spike of 2.05ms isn’t huge, but I’m just curious if this seems in line with expectations?


#6

Hi

That seems reasonable I think.
The most effective ways to reduce the cost is to use a lower erosion iterations value (grid graph settings), use a lower collision diameter setting (grid graph settings), or use a lower grid resolution.

Note also that the performance in the Unity editor is usually lower than in a standalone build.