Never does this script run this poorly. While it does usually average about 3-5%, its handling the bulk of AI logic so thats fine. This is just ludicrous.
Expected behavior
I expect PathfindingService to use reasonable amounts of server resources and not entirely throttle an experience despite moderate to heavy path usage.
As you can see via the replies, this doesn’t appear to be an isolated incident.
Bump, I have noticed this behavior in my own experience. Pathfinding performance has been consistently worse on the same project for me in the past month.
On top of these performance issues, the pathfinding part itself seems to degrade. Here is a video captured in Marioman73’s Experience (Realish Reborn) of NPC’s failing to pathfind down a simple slope.
Thank you for reporting the severe performance degradation concerning PathfindingService. We understand that this is critically impacting your experiences, especially those that rely heavily on NPC navigation.
To help us investigate this issue effectively, we would greatly appreciate it if you could provide the following information:
Key Information We Need
ImprovedSearch Usage:
Are you currently using the new ImprovedSearch feature for pathfinding in your experiences?
Reproduction File:
If possible, please provide a minimal reproduction file that can be run in Studio. This file should clearly include the running instructions, the scenario where the issue occurs, and the expected behavior.
MicroProfiler Dump:
When the performance degradation is happening, please record a MicroProfiler dump. You can find the instructions on how to do this at MicroProfiler → Profile the server. This data is invaluable for diagnosing runtime performance issues.
General Pathfinding Performance Tips
While we investigate, here are some common factors that significantly impact pathfinding performance. Reviewing these in your code might offer a temporary workaround or point to an area of unexpected load:
Avoid Moving Non-Humanoid “CanCollide” Parts: Try to minimize the use of non-Humanoid parts with CanCollide enabled that move continuously, especially over large areas. When a CanCollide part moves, the pathfinding system must regenerate the navigation mesh (NavMesh) in the affected area, which is a very performance-intensive operation.
Limit Path Length: Avoid calling FindPathAsync for extremely long distances (e.g., greater than 1000 studs). A single long-distance call generates a large NavMesh and requires an extensive search. If possible, breaking a long path into multiple shorter, sequential pathfinding calls will generally improve performance.
Throttle FindPath Frequency: Do not call FindPathAsync every frame. For NPC-chase scenarios, the player’s movement in a single frame is negligible, and often a significant positional change only occurs over several seconds. Calling FindPathAsync less frequently (e.g., once every few seconds, or based on the target’s distance change) can drastically reduce server load while maintaining acceptable gameplay.
We appreciate your patience and detailed reports as we work to resolve this. We look forward to any additional information you can provide!
I’ve linked a message containing several microprofiler dumps and a script profiler dump.
UseImprovedSearch is enabled
I’ll still be trying to work on a reproduction file.
From current rudimentary testing this doesn’t seem to have an effect on servers started within the past few hours, perhaps it got indirectly fixed in Release 700? That being said I would not consider this issue resolved at the moment as more testing must be done.
The current server instance I’m in is experiencing it.
ServerID: 0bfd1923-b5f5-45d3-b14c-879333b9675b
15931801756
Place Id: 15931801756
Experience: Noobs vs Zombies: Realish Reborn - Roblox
Thank you for providing the microprofiler dumps and confirming that UseImprovedSearch is enabled.
Unfortunately, I cannot directly log into your specific server instance.
However, the microprofiler data clearly shows a high cost in pathfinding, specifically within the NavMesh search process (as opposed to NavMesh generation).
Could you confirm whether, during the frames captured in the microprofiler dump, your NPCs were attempting a large volume of long-distance findpath calls?
I will continue to investigate based on this data.
I would say on average the max distance of computation would be about 1000-1300 studs in those cases. This was operating under the ruleset of PathfindingService from BEFORE the ImprovedSearch was released. I noticed that paths would pretty much consistently error if distances were > 2000 studs, and so I didn’t allow NPCs to pathfind if the distance was more than that.
Assuming the initial path fails (the one with a distance of about 1000-1300 studs), npcs will then find a list of nodes connecting in a path close to their target position using a custom nodemap of mine. Afterword, they would compute paths and move from one node to the next, with those distances being anywhere from about 60 to 140-200 studs.
There would usually be about 50-70 NPCs, each computing a path likely at least once every 5-7 seconds. I think it’s also worth noting that the agent parameters of all the npcs could vary wildly, in terms of agent configurations and costs for various labels and materials. I also use a significant amount of costs, some of which are at higher amounts like 100-200 or even infinite (math.huge) depending on circumstances.
Again, I operated under the assumption that paths should have a maximum distance of about 2000 studs, as that was what the previous system allowed for (even if it meant paths took a bit longer to compute).
Marioman73, thank you for confirming the distance details.
Longer distances pathfinding is likely the main source of the high pathfinding cost we observed in the microprofiler dumps. Longer distances require significantly more computational resources for the NavMesh search.
Since the core Pathfinding Service hasn’t been updated in months, this performance change is tricky to pin down. This makes me wonder if there’s an external, related factor.
@MoIitor: You mentioned that this issue started for you around the “Server allocation update” a month ago. Could you please clarify what “Server allocation update” you are referring to? Also, is the pathfinding performance problem still occurring for you? If so, could you please record another MicroProfiler dump for the server? Instructions can be found under MicroProfiler → Profile the server.
We appreciate your continued help as we investigate this!
I’ve also noticed new behavior with this issue, it seems to sporradically happen depending on which region a server is hosted in. Such as Singapore region servers having horrible performance while North American servers maintain sufficient performance.
Do note that what I mean by region differences is that this issue still occurs, but moreso in some regions.
I will try to record a new microprofiler dump when I am next available.
