Performance issues in OdinEditor.OnInspectorGUI() for large lists of objects (~1500 objects of 5 properties each)

[Kasper Christensen]

(Context)

Using EditorOnly mode for Odin. ScriptableObject instance (BrainProfileScorePercentilesSO), with a list of ~1500 objects, each object having 5 simple properties (int, float, string). BrainProfileScorePercentilesSO properties are decorated with odin attributes, child objects are likewise. Both BrainProfileScorePercentilesSO and child objects have odin validator functions attached to one or more properties.

What happened?

When selecting a scriptable object asset/instance in the project view, the inspector draws the object. When drawing the object using odin attributes, the editor lags tremendously. When profiling it seems to all originate from OdinEditor.OnInspectorGUI(), which is overridden in a custom editor for the scriptable object type, however the original logic is kept by calling base.OnInspectorGUI(). Seems to take roughly 300ms per frame when the inspector has to draw, regardless if list is collapsed or expanded. When deep profiling the editor it takes 4000+ ms per frame, with some deep calls inside PropertyTree reaching 60000+ calls!

Fun fact: Saved the Unity Profiler session to a file.. the saved data file is 2.34 GB!?

Related issue: https://bitbucket.org/sirenix/odin-inspector/issues/79/performance-issue

How can we reproduce it?

I dont have a repro-project, but i believe this isnt super specific to our project.

1) Create a list of objects with 5 simple properties each, and populate the list with ~1500 objects with random values.

2) Observe that the editor lags when scrolling or otherwise interacting with the inspector, as Unity issues draw calls to the odin editor.

If screenshots would help explain or demonstrate your issue, please include these.

Inspector Screenshot

http://prntscr.com/hqwno3

Profiler Screenshot 1 (Profile Editor + Deep Profile): List collapsed

http://prntscr.com/hqwn17

Profiler Screenshot 2 (Profile Editor): List collapsed

http://prntscr.com/hqx391

Profiler Screenshot 3 (Profile Editor): List expanded (15 items per page)

http://prntscr.com/hqx45i

I have also attached some code snippets (i cannot share the code in its entirety, sorry!) if these would help to see if i did anything wrong/stupid in my usage of the Odin inspector framework.

What version of Unity are you using?

Unity 2017.1.1f1

What version of Odin are you using? (See "Tools > Odin Inspector > About")

Odin Inspector version: 1.0.5.3

Editor Only Mode: Enabled

What operating system are you on?

OS: Windows 10

CPU: Intel Core i5-6600 (3.3 GHz)

RAM: 8 GB

[Kasper Christensen]

For anyone else experiencing this issue, I've added a hack in the beginning of my custom editor, where i can toggle on/off Odin inspector (so my custom stuff wont lag, but it defaults to use odin, so i still see if validation fails)

I put this in the beginning of my OnInspectorGUI() method in my custom editor to alleviate some of the lags:

drawOdinEditor = EditorGUILayout.Toggle("Draw Odin Editor", drawOdinEditor);
if (drawOdinEditor)
{
    base.OnInspectorGUI();
}
else
{
    DrawUnityInspector();
}

[Tor Esa Vestergaard]

Thanks for the excellent and detailed report! This is a known "issue" - currently as designed, the property system does a "full data update" and processes all data in the entire inspected component/object every time there's a GUI frame. This means every object in the entire list is inspected, its data is stored and compared for value conflicts, we check against object->path dictionaries for most reference types to resolve potential cyclic references. If the inspected object is an Odin-serialized prefab instance, it gets far worse, as every frame we do delta comparisons of all Odin-serialized data against the parent prefab, and ensure that there's a set of prefab modifications registered that will result in those changes compared to the parent prefab, and so on.

We did it this way because Unity's system is designed to work this way, and because we favor things working really well, over things being really fast. However, we are transitioning to a lazy-evaluation property pattern with patch 1.1, and that will help a lot as you then only pay the data update cost for whatever is actually queried every frame (so generally what's visually rendered, meaning list paging will also help). Tentative date for release is late January/February - no promises though! There'll be an open beta before then for people to try it out. 1.1 is a huge refactor of Odin's property system and it will need to be tested exhaustively. Prefab instances will probably still be very slow, though - there's not very much we can do there without sacrificing reliability.

( I should note that 1.1 is not the next patch containing the new editor window features, which should hopefully drop pretty soon. )

[jnuneztorrijos]

You already show lists in a partial way when they are too long. Perhaps you could copy the part of the list you will show, you inspect only the copy and check for possible conflicts, and then you show only the copy. Everytime the user moves towards a new section repeats the same. Perhaps its more complicated than what I'm saying, but there must be alternative solutions or workarounds... I'm working with very long lists of complex objects and is getting impossible to see anything. Besides this issue, Odin has been a blessing to me, I'm very happy with it, but this particular issue is giving me headaches. I would realy appreciate a solution, and I bet many others would too.

[Bjarke Elias]

We'll begin beta-testing of 1.1 very soon, where it runs a lot smoother. You can read more in our latest patch notes of 1.0.6.1 down at the bottom. And we're looking for early beta-testers, so if you're up for it, write us a mail from sirenix.net/support with your Odin invoice ID, and we'll hook you up with the beta once it ready. Hope to start the beta-testing this month, but it might be next month if there are unforeseen bumps ahead. Which there often are.

[Tor Esa Vestergaard]

Fixed in 1.1, which is now in beta.