Posts: 2
Threads: 1
Joined: Feb 2020
02-05-2020, 06:40 PM
(This post was last modified: 02-05-2020, 07:13 PM by TdayMFG.)
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).
Posts: 2,114
Threads: 92
Joined: Jun 2017
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 helps immensely. Thank you.
Available for freelance work—feel free to reach out.
Posts: 2
Threads: 1
Joined: Feb 2020
(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.
Posts: 2,114
Threads: 92
Joined: Jun 2017
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 helps immensely. Thank you.
Available for freelance work—feel free to reach out.
Posts: 2,114
Threads: 92
Joined: Jun 2017
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 helps immensely. Thank you.
Available for freelance work—feel free to reach out.