Post by KaiClavier in Unusably slow

Viewing post in Unusably slow

Been looking into it and yes, in Unity 6 at least, in this specific scenario, something is going wrong... Long text on a prefab causes a huge delay - Tried it both with a prefab that had a small amount of text and a big amount of text too - the small one was extremely bad, the big one still bad vs non-prefab text but still noticeably slower.

Found a thread here about the issue: https://discussions.unity.com/t/extreme-slowdown-traced-to-serializedobject-appl...

Seems like it's not specifically my fault, and the solution here is to not actually store any text on the mesh, just send it when it needs to be sent.

Still digging into this more though... The problem code I'm seeing is absolutely editor-only, a call from stm.OnInspectorGUI() triggering SerializedObject.ApplyModifiedProperties()... Both of these are only called in-editor and specifically if the inspector for the currently inspected object is open.

So... until Unity provides a way to work around this or a deep profiler that will actually tell me something I can fix, my advice is to not type a ton of text on the asset directly in the editor and instead have something else that will send text to the object. The prefab can be set up in advance, but the issue seems to just be editing a large amount of data in the inspector of a prefab in newer versions of Unity for whatever reason.

A dialogue manager would work for this, but if you want to edit text in the editor, here's a super-basic sample script to work around the issue... I'm not 100% sure why this works while the default inspector itself causes lag, but please try putting this on the same GameObject, and collapsing the inspector for SuperTextMesh. I seem to be able to edit text very smoothly with this method:

https://pastebin.com/fNFGPiNV

I'll keep thinking about how to work around this though as the issue is clearly something with the inspector for SuperTextMesh, since collapsing it and using this component instead has everything run smoothly... Will keep looking into that!

EDIT: more findings, it's for sure linked to serializedObject.ApplyModifiedProperties() - if I tell the STM inspector to return after the text field and call it immediately - there's still a delay. If I remove it... no delay, but the text of course doesn't update since ApplyModifiedProperties is needed to... apply the properties. So I think the extra code I wrote above just gets around this by... not using a custom inspector...? Doing even more digging...

Neon Specter71 days ago

Interesting. I use ApplyModifiedProperties in my own rich text editor and have no performance issues whatsoever even with very large amounts of text.

I built this system a while ago (and in a hurry), but I recall running into some major issue - not sure if it was a performance issue, but looking at my code I see I have delta checks and dirty flags for the text and comments saying to only call ApplyModifiedProperties when necessary.

I took a brief glance at your editor and it seems like you might be saving a lot of different properties in OnInspectorGUI and I don't see anything that checks if calling ApplyModifiedProperties is actually necessary (though I think it should just return if there's no changes, but according to your testing it seems like just the call itself is the issue). This would mean you're calling ApplyModifiedProperties every frame while the editor is visible (unless I'm mistaken).

I did try adding a HasModifiedProperties check before your ApplyModifiedProperties calls, but it didn't help - maybe it's just the number of properties you're trying to save every frame (or maybe HasModifiedProperties has the same issue). I can confirm, however that commenting those calls out solves the performance problem.

KaiClavier71 days ago

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!

itch.io

Viewing post in Unusably slow