Heavy performance impact - bad setup?

General
#1

Hello,

I have a very strong performance impact using Astar Pathfinding Project Pro.
The profiler shows up to 25ms and over 20% of the CPU usage. I attach a screenshot of the profiler and my setup for the individual AI´s. In my scene there are 80 of these individuals. I know that this is quite a lot, but the repath rate is set to 8 seconds and I wasnt sure if I simply made a bad choice when I setup the individuals. There are so many different scripts and options that I just took one of the examples and modified it.

Could you have a quick look at the setup? I dont really understand what exactly causes the enormous performance impact if not the path processing itself.

Astar_Screenshot.png1200×800 134 KB

#2

Hi

From the profiler it looks like AIBase.FixedUpdate is called 950 times, if you only have 80 agents that means FixedUpdate is called approximately 10 times per frame. Do you perhaps have Unity Time Settings -> Fixed Timestep set to an extremely low value? A common value is around 0.02. Also note that having deepr profiling enabled will slow the game down significantly.

#3

Thanks for the extremely quick answer.

Timestep is at 0.02.

In my screenshot the upper one with 20.9% CPU usage, 20.2ms and 950 calls are with normal profiling. I wanted to give information what exactly takes performance, so only the second more detailed window shows the deep profiling.

The regular profiling only shows:
FixedBehaviourUpdate: 450-900Calls . 8-15ms . 50-60%

So this is not the expected performance?

Maybe I should add, that I constantly destroy and add pedestrains around the player, but only when they get out of a specific range. This maybe explains the fluctuation of calls. The amount of pedestrains never exeeds 85-90.

#4

Hi

So in Unity the FixedUpdate is guaranteed to always run at that exact fps. So it will always run at 50 fps. In your case it seems like your game is running at 5 fps or something, but then the AIs will run 10 times per frames which is why it takes up such a large amount of time.
90 agents really shouldn’t be that slow. Several hundred agents should be able to be simulated with no major performance issues.