Right, even though I tried changing it so ApplyModifiedProperties() calls and returns if text is being edited, it is still happening every frame. I tried making it call it only if text is currently being edited and stop rendering the rest of the inspector, but that also makes it happen every frame for that... And just tried wrapping ApplyModifiedProperties() in both a hasModifiedProperties and GUI.changed check, and it didn't make a difference, either. So yes, I suppose it's just trying to save too many properties...? I'd expect ApplyModifiedProperties to only apply what was actually modified, but I guess it must be going through everything if both putting a check for hasModifiedProperties and calling it and returning if a change occurred makes no difference. Even getting rid of the serializedObject.Update() call at the start and making it so ApplyModifiedProperties is called *only* when text updates still doesn't show a performance boost.
The extra script I wrote gets around this for sure, but I'm trying to figure out what I can actually apply from that workaround to the actual issue... Maybe when the custom inspector is edited, all properties are being marked as modified somehow? Or maybe the extra script can edit this property directly without needing to apply the entire object? I *could* try switching it so that the stm object is edited directly, but I thought using the serializedProperties was supposed to be the more lightweight and safe option.
Another thing I found - even if I'm calling ApplyModifiedProperties() every single frame, if I switch the text area's code like this:
//EditorGUILayout.PropertyField(serializedObject.FindProperty("_text"));
stm.text = EditorGUILayout.TextArea(stm._text);All of a sudden, performance goes way up. (Not as extreme as the extra script, but it's actually usable) but the values don't actually save. Doing a change check and using EditorUtility.SetDirty(stm) after causes the same slowdown but now the values
Assuming SetDirty() is slowing down because it's marking *every* field for serialization, and ApplyModifiedProperties() slows down because every field is becoming modified... Maybe all my calls to FindProperty() are setting these properties as modified somehow even though they're being read not written...? I went ahead and tried changing every FindProperty() call to be a SerializedProperty field and setting the values during OnEnable() instead, (this took quite some time...) but this still gave a laggy result so I don't think this makes a difference somehow.
Maybe the reason this happens with prefabs in newer versions is that some type of modification flag is being set on all instances of the prefab now and the difference between *all* changed flags with the original?
I did find the existence of this: https://docs.unity3d.com/6000.0/Documentation/ScriptReference/PrefabUtility.Reco...
...But the documentation says that if you're using serializedObject and serialziedProperty right, there's no need for it...?
So I'm really not sure how to actually make it run smooth by itself (and work correctly) right now with all these different things that have been tried. It seems as if every property is being marked as modified (possibly due to the prefab setup - that thread I linked before was from 2020 and seemed very specific to this scenario) or ApplyModifiedProperties() considers a prefab to always be modified anyway. The workaround script I wrote gets around the issue, but if there's a genuine solution to improve editor performance, I'd like to do it!! Like I always knew the Unity editor introduced some overhead for my asset, but wow does it run *smooth* with that extra component, even increasing performance outside of a prefab. I want to make the default inspector work as good as that does!