Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Lots of Allocs in Editor Update (Poor Performance in Editor)
#1
There is significant slowdown when using the spline tools with a significant number of splines in the scene. Upon profiling the editor, it's noticed that the GC allocs inside the EditorUpdate delegate calls in the various curvy scripts grinds the editor to a halt.

Whatever seems to be causing the editor slowdown fortunately doesn't seem to affect in game performance but this makes it night unusable to go into the scene view.

Any ideas of what the cause might be here? A deep profile with call stacks simply  says there's a GC alloc but there's a lot of code to sift through. Any help is much appreciated!

EDIT: Wanted to add a few details, there are no generators in the scene but there is essentially a 20x20 grid of splines with more splines connecting the diagonals of each grid square (so, that's a LOT of splines).
Reply
#2
Hi,
It seems to be something related to gizmos display. Try reducing the amount of displayed gizmos and see if the perfs are better. If things are still too slow, then please send me a reproduction case if possible.
Please consider leaving a review for Curvy. This will help a lot keeping Curvy relevant in the eyes of the Asset Store algorithm.
Reply
#3
(02-05-2020, 09:51 PM)_Aka_ Wrote: Hi,
It seems to be something related to gizmos display. Try reducing the amount of displayed gizmos and see if the perfs are better. If things are still too slow, then please send me a reproduction case if possible.

This definitely does improve the performance considerably, I will make sure my team knows this...

Any ideas on optimizing or improving this? Our use case currently is very procedural so no one really needs to hand edit the gizmos but in the future this could quickly change.
Reply
#4
I assume the following scenario, which is the most common one, but if yours is different please let me know:
The amount of the displayed control points is in the tens or hundreds, and the amount of displayed spline approximations/orientations/tangents is in the tens of thousands or more. In such scenario, hiding the gizmos of the control points does not change performances that much, so you can keep them, and those are the important gizmos for hand editing.
So hiding the gizmos of approximations/orientations/tangents should be enough.
As a last resort, you can set the Show Gizmos in the Curvy Spline's inspector to false. This will hide the spline's gizmos except if the spline is selected.
The gizmos displaying code should be optimizable. I will take a look at it at some point. Please let me know if things become unbearable for you.
Please consider leaving a review for Curvy. This will help a lot keeping Curvy relevant in the eyes of the Asset Store algorithm.
Reply
#5
Hi,
I did some preliminary work on this. The CPU usage boils down to these Unity methods: Gizmos.DrawRay, Gizmos.DrawCube and HandleUtility.GetHandleSize. These methods seem to not be efficient enough when called thousands of times. I might get some 10% or 20% perfs with some small improvements, but the real optimization (things like twice as fast, or an order of magnitude faster) would mean writing my own batchable alternatives to these methods.
Like I said earlier, I will work on this later, but I thought you might be interested in my preliminary work.
Please consider leaving a review for Curvy. This will help a lot keeping Curvy relevant in the eyes of the Asset Store algorithm.
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Performance on Mobile (Android) g0tNoodles 3 3,491 01-24-2020, 12:05 AM
Last Post: _Aka_
  Lag in editor, trying to optimize it UsernameHed 2 412 10-10-2019, 08:04 AM
Last Post: UsernameHed
  Disable the Update of the CurvySpline UsernameHed 8 1,784 05-29-2019, 01:13 PM
Last Post: _Aka_
  Spline Controller Position Force Update ? UsernameHed 1 832 05-16-2019, 12:20 PM
Last Post: _Aka_

Forum Jump: