I’m seeing a load of misinformation on Pathfinding performance. Back in May I wrote an article getting into Pathfinding (PF) performance. See: #SL Pathfinding Update Week 20. Scroll down and read the section on The Size of the Problem.
PF has several different aspects. One could break it into two main parts. One is the part where PF figures out where everything is in the region and how to treat it, as what are obstacles and where are the paths. This is a slow and calculation intense process. But, it really only has to run at region start up, when a region’s ground topology changes, or things are built on the ground. It is sort of an initialization process.
Another part is when PF has to find what has moved, like a door opening. Things like a door that cut across paths are called cuts. PF has to find things that move and ‘cut’ the Navigation Mesh mostly referred to as Navmesh. The cut calc’s are very fast. They only need to revise the previously calculated Navmesh.
The Navmesh initial calcs take time measured in tens of seconds. Recalculations of the Navmesh are minimized as much as possible. But they at least run in a separate server thread. This prevents the region and other regions in the simulator from freezing until the calc is completed.
With region idle there are more CPU cycles available for PF calcs. If you are thinking what happens at grid wide roll outs, consider that a server is brought up with the new software and then regions are moved into it. Most of these regions will quickly drop into Idle Mode as no one is in them. So, the initialization of PF should happen pretty quickly and likely before most people return to the region.
The cut calcs are fast but they are capped at 4ms. This is 4ms of script frame time, which is 22ms for a region running at full speed 22ms or 45 FPS. (4/22=18% and seems huge huh?)
The thing is the 4ms can only be taken from free script time. If the region is overloaded and lagging the PF calcs for new cuts will never run. So, opening a door will not register on PF and the Navmesh will get out of date. PF characters will not go through the open door. If it it is recently closed, they won’t notice the closing and will pass through it. The result is the rest of the region having priority will run at pre-PF speeds. It is PF that will degrade not the region.
The character updates are handled very much like path cuts. The time they can use is also capped. Somewhere in my Pathfinding articles is the time required to handle character updates. While we measure time for most things in SL in milliseconds character updates are measured in microseconds. As the caps are hit we’ll see PF characters slowing down. Again they slow down before the rest of the region does.
In early May I was worried about PF performance and what the system was going to do to non-optimized regions. I took some heat for that. The Lindens corrected every concern I had… or maybe they just started explaining what they were doing better and I had misunderstood.
Whatever the case I doubt those turning off PF for performance reasons can measure the difference in region performance.
The regions with the Debug versions of PF will tend to run slower, because of the debug code. I doubt any such versions are running on the main grid. But, most of the previous versions were likely to have debug code, so be careful comparing past performance with current performance.
Scroll down to see Lorca Linden’s comment.