koobas.hobune.stream
How to optimize a custom editor ?
Hi there !
I was working on custom inspectors when I noticed that it was really laggy when working on large collection (over 1000 elements) to the point it's not usable while Unity default inspector is with similar data for the same inspector. I noticed by commenting out code that it was Update()/UpdateIfDirtyOrScript() that was mainly causing all this, doing a lot of stuff even when no modification was made in Inspector. While necessary to serialization, there's definitely a way to make it faster since Unity does it !
How can I optimize Update/UpdateIfDirtyOrScript calls so that it's called/do stuff only when necessary ? (a change in my inspector)
Thanks in advance for your answers :)
You should show code when asking for optimization tips for it. Without code, the best we can tell you is don't do stuff that's not needed. But you obviously know that already.
GUILayout elements are "expensive". If you can show only the ones that are visible you might gain performance.
Use an EditorGUI.Begin/EndChangeCheck pair to force update execution to only happen when the user actually does something (text fields and such will still be laggy).
Double check to make sure you're not using an element of the serialized object as an editor state (e.g., most of my classes have "inspectorOpen" variables used by various inspectors to open/close foldouts)
Try moving Update to OnDisable.
Jamora : I agree with you, but actually, I can't really upload my code. In fact, I work on automizing Editor generation with reflection with advanced features like property support, groups etc. (pretty much like Pimp$$anonymous$$yEditor in a way) There are a lot of classes to retrieve/store reflection metadata, reference to SerializedProperty and handle the way a particular type should be displayed, so it's kind of huge. Uploading it is quite complicated.
Loius : I have no trouble with EditorGUILayout, it's really just Update that reduces performances noticeably on large collections. Concerning ChangeCheck, I already do that but it does not seem to do much. Concerning foldouts, I use SerializedProperty's isExpanded property to store wether a particular foldout is opened or not. It does improve performances when large collections are closed, but there's no lag at all when not updating stuff. So I guess the answer somehow resides in how serializedObject.Update() works. Concerning OnDisable, I'm not sure to understand what you mean.
Edit: Haven't noticed that this post is so old at first but i'll leave my answer here anyway. Maybe it's usefull for someone else stumbling across this post at some point in the future, in which case: Hello future person :)
Everytime your mouse enters a new window / a different window is set in focus, all your calls to methods in 'OnInspectorGUI()' will be executed. To prevent this make use of 'ChangeCheck()'.
public override void OnInspectorGUI()
{
// at the very begining start the change check.
EditorGUI.BeginChangeCheck();
...
... // content
...
// at the end check if any changes happend and actions / calls to methods are necessary.
if (EditorGUI.EndChangeCheck())
{
// call to apply new values
ApplyNewValuesToObjects();
// repaint the inspector
Repaint();
}
}
This way your objects will only be updated / get values changed if you changed something in the inspector (EditorGUI.EndChangeCheck() returns true).
You might want to do stuff such as getting the serialized object only in OnEnable (ie when the object is selected ).
Also, maybe listen for events to avoid ApplyModifiedProperties every frame.
See catlike's excellent tutorial, which might help.
Hi, thanks for your answer :)
Actually, I already get my SerializedProperty in OnEnable. The only case I don't is when I change my array's size in Editor, but even then, I cache newly created SerializedProperty in a data structure. Concerning Apply$$anonymous$$odifiedProperties, I don't think that's the problem. When I commented out my call to Apply$$anonymous$$odifiedProperties, there was very little to no performance gain while when I commented out Update/UpdateIfDirtyOrScript, the performance gain for large collections was really huge.
I'm kind of stuck here, I really have no idea what I should do. There's obviously something I'm doing wrong :(
This thread is ancient, but since it's one of the first results on google, I figured I'd link to a satisfactory solution I found for folks still looking to squeeze out more performance.
https://forum.unity.com/threads/slow-custom-editor.328579/#post-4422910
