Support Forum

Bad performance in RemoveDestroyedGizmoDrawers()

I am noticing the problem in A* pathfinding pro, but this is an issue with ALINE in general. With NodeLink, we currently have 7000 registered drawers and this takes a substantial amount of time.

Please try to find a solution that does not involve looping through all the drawers each frame. If possible allow using ALINE from anywhere, that way you won’t need to call your own DrawGizmos()

Hi

Do you think you could disable deep profiling and instead add a Profiler.BeginSample and EndSample to just that function and see if it is still slow? Deep profiling has a tendency to skew profiling results and these profiling results look a bit weird to me. RemoveDestroyedGizmoDrawers shouldn’t be slower than “Draw Gizmos”.

You can use ALINE from almost anywhere. Use it in your Update function for example, it will work perfectly fine. I would not recommend using it inside Unity’s OnDrawGizmos method though because that one is called multiple times per frame at odd places and that will cause a lot of problems.

Still a major cost

It’s because of the !mono null check with the implicit bool operator. This is expensive, especially in tight loops.

That is indeed pretty slow. Are most of your scripts not drawing anything? I find it hard to believe that the !mono check would be slower unless most scripts were just rendering nothing.

Indeed, they’re not drawing anything. I am simply in the game view, playtesting my game.