Pathfinding with NavMeshAgent or NavMeshQuery creates garbage

Hi,

I would like to do high-performance pathfinding using Unity's navmesh system. However, the current built-in functionality for pathfinding - either by using NavMeshAgent or the asynchronous NavMeshQuery - creates garbage and causes regular GC events (and thus latency spikes) at around 100 agents.

Incremental GC isn't really a solution, and in my tests it was hardly helpful. I still get latency spikes that reduce my framerate from 200-300 to less than 90 every 5-10 seconds. With pathfinding turned off, I don't get any GC events because the rest of my code uses structs and the Job system.

This is really a shame because:

1. Pathfinding is a core feature of most games.
2. Nowadays it's totally possible to build an otherwise garbage-free game using structs and the Job system.
3. GC events are extremely detrimental for VR applications where steady framerate is absolutely critical.
4. Most of the advice on the internet currently is "use Incremental GC" but this is a marginal improvement at best.

I'm creating this thread to voice my opinion and get feedback from the Unity team. I really hope this is on your backlog.

 

NavMeshQuery isn't allocated on the managed heap. Native collection allocations will show as allocations in the profiler, but that's native memory not managed heap. Also NavMeshQuery is designed to be reused, you shouldn't be allocating new ones all the time.

 

Sorry for not being clear. The execution of NavMeshQuery generates garbage. I did not mean to imply that the NavMeshQuery struct itself is a managed allocation - obviously this is not the case. There is something more complicated happening behind the scenes when this job executes. As I described in my original post, I was able to isolate the GC events to being caused by the pathfinding, regardless of where the process originates from.

 

There must be something else going on, we definitely don't see this behavior in our job based pathfinding. And we do a couple hundred queries per frame at peak.