Significant editorloop performance drop when only certain objects are selected in the inspector.

I've had this project since ~2017 in roughly similar state and haven't worked on it actively since maybe around 2018.3.

I've updated it to 2019.1 and 2019.2 as they came out but didn't notice any issues. Now recently I updated it to 2019.3 and I've been starting to work on the project again, but if I select certain objects in the hierarchy I get really bad editor lag:



Noticed it in 2019.3.5
I've tried backporting to 2019.3.0, but the same issue persists.
And I tried updating to 2019.3.7f but the same issue persists.
I have not yet tested 2019.1 which is the oldest version I still have installed on Hub.
A friend who I've been working on the project with has updated to the most recent Unity version and has a much worse CPU&GPU than I do and doesn't have the issue.

The objects I select don't have custom inspectors.
And I'm confident this wasn't the case before, because it's happening when I select the player object, and in the past I had selected the player object thousands of times during playtesting. Now it immediately drops to sub60 fps in editor when in both play mode & non-play mode.

Not sure how to approach it.

 

I tested an old old 2018.1 version of the project
updated it to 2019.1 i had installed in hub, and it worked normally
updated it to 2019.2 i had installed in hub, and it worked normally
updated it to 2019.3.0 and the editor performance issue started.

When I click specific objects in my scene, (objects with scripts with no custom inspector), there's a big editor slowdown as shown in the profiler pic above.

Interestingly enough, if I click on child objects of those objects, then the lag goes away. It's just these specific objects and I can't pinpoint a similarity between them.

 

Just narrowed down the commonality between the objects:

Intense editor slow down ONLY with the inspector open and showing the selected object that has ANY Collider2D type with the Info dropdown menu expanded. As seen here:


If I minimize the Info dropdown menu, the intense garbage creation and editor lag shown in the original post vanishes.

^ Nevermind. I'm still getting pretty major editor lag, though the info thing definitely changes it from constant lag every GUI repaint to just intense spikes.

 

I'm seeing the exact same thing.

Trying to view any value in the inspector while the game is running in the editor is borderline impossible. My game lags so bad that it even stops functioning properly. Collision detection and raycasts etc. aren't working as intended. I don't even know if this is also highlighting framerate dependency issues in my game or if it's just straight up broken. I'm leaning towards the latter.

I've never seen this in Unity before. I'm on 2019.4.2f1 now.

It gets worse the more components I have open that change every frame, like the transform, collider info, audio source etc., but having something like the player selected as he's moving around lags the game to death even if every single component is collapsed.

I haven't looked in the Profiler, but I just looked with Rivatuner enabled and this is how it looks then. Framerate with the player object unselected vs selected:


And I'm not even moving. Nothing is changing as the player is standing perfectly still and yet Unity goes crazy.

 

I submitted a bug report for this. It's reproducible in a fresh project by just selecting either the default camera or directional light while in play mode and it gets infinitely worse by adding components like 2D colliders, audio sources or any other components which show realtime data from the game.

 

Bug report: https://fogbugz.unity3d.com/default.asp?1266360_gtis15hpblpp8l7q

They're saying they can't reproduce it when it's impossible for me not to reproduce it. Any help is appreciated.

 

This thread may be talking about the same or at least a similar issue for what I can tell: https://forum.unity.com/threads/case-1158368-hierarchy-window-performance-degradation.684280/

 

That other thread taught me how to profile the editor and then this is what I found. The first image is with the Main Camera selected with an Audio Source and Box Collider 2D component on it and the second image is with the camera not selected. This isn't even during play mode as I assume the editor profile just runs continuously as the editor runs?

 

I haven't visited this in awhile, but I do have some more, mostly useless information that probably doesn't help.

I believe I was wrong when I thought Collider2D/Rigidbody2D played a role in the lag. They do contribute but they're not the actual problem.

I have two versions of my main project that branched from each other at around 2019.1.
They're roughly 90% identical except one is the 'main' one and one I just made for testing random things and packages and assets I didn't want to muddy the main project.

My main project is the one with the issue that I brought up with this post after updating to 2019.3. I only just now realized my test project which is what I first updated to 2020.1 a few days ago has the same 'issue' but to a much lesser extent despite being roughly the same. To test, I updated my main project to 2020.1 and it still has this issue.

I believe now that the issue is likely due to something I must have done on my end somehow.
Here is the profiler of my main project again of the significant lag when drawing the inspector with a problem object selected.


In my test project, to clarify, the same problem is actually still there in the profiler, but to a less extent so I didn't notice it because it never brought me to a noticeably low framerate.

Here's profiler of test project with same exact object selected in a different but similar scene (which shouldn't matter because all the lag is coming from editor drawing the inspector).


Important to note that these spikes only occur when one of the objects I'm selecting is changing in some way in the scene, such as transform being updated (in play mode, which happens every frame). I understand that it must be the inspector needing to update values of the monobehaviors and transforms which requires some amount of garbage creation, but what I don't understand is why it's so different between my two projects, and why updating to 2019.3 originally caused such a significant drop in performance that 2020.1 didn't fix for me. And again the backup versions of the project (that are 99.9% identical) that open with 2019.1 and 2018.3 and below don't have the issue at all.

The reason it's a problem is that when in play mode, this large inspector drawing time of the selected objects is added to the regular playerloop time, which drops fps well below 60. So it makes testing script changes of those objects' impossible since I have to have them selected to see inspector values, but the fps is dragged to a slow from all the inspector garbage creation which makes it so I can't reliably playtest anything.

It has to be a mixture of something I'm doing on my end that 2019.3+ handles differently and doesn't like, but I can't imagine what. I'm not using any custom inspector script on the problem objects. Not sure what else to do to figure out why.

Minimizing all components including the transform component on the object has some beneficial effect but doesn't fix the problem.

 

My issue at least was not reproducible in 2020.1.

I'm hoping a fix gets backported to 2019 LTS because I have no intention of upgrading until 2020 LTS arrives.

Here's my bug report, which is now closed:
https://fogbugz.unity3d.com/default.asp?1266360_gtis15hpblpp8l7q

And this is apparently the corresponding request for a backport to 2019.4:
https://issuetracker.unity3d.com/is...e-component-is-opened-in-the-inspector-window

 

I now have a similar bug. If an object has a Rigidbody and the info panel is expanded, it'll drop the FPS in the game window by 20. Hopefully this does not translate into the full build, since hierarchy selection apparently affects runtime.

 

We are seeing the same issue in 2021.2 alpha. We've been mostly on the latest alpha for more than a year now and this issue has been around all along. It's getting worse the more complex the objects become so I finally decided to do some profiling and research which is why I stumbled upon this thread.

As far as I can tell this is not related to any specific component such as RigidBody, AudioSource or anything but simply seems more or less correlated with the number of expanded components with changing values in the inspector at any given time. It also seems a bit boosted (as in even slower) if the selected game object is a prefab.

We've also experiencing the same issue when going from the game tab to the scene tab and back again. Dropping from around 100 fps to 10-20.

Given that you say this was fixed in 2020.1 (which we were using a while back when it was alpha) it makes me wonder if the fix hasn't yet reached the non official release streams. (We've been on the beta for a while too and the issue was there as well).

Unfortunately since we are using the some of the latest features in URP we can't go back to a none alpha version to test this.

 

Nah, TwiiK said he was not able to repro this in 2020.1, that's what I was referring to.

No I do not believe this has to do with the RigidBody2D component and it's repaint. If anything related a guess would be any component doing a repaint of its updated inspector content. And the more of them doing it the slower it become.

We are seeing some rather big frame drops just be expanding the transform component compared to having it closed.

Did the new editor change from using the old UI framework to the new? Implying a need to wrap old component inspector editors?

 

I'm aware this is not you area of expertise but I do appreciate someone from Unity replying at all! So thanks for that!

Right, well it's obviously hard to reason around what could cause it but it sure seems related to the new UI stuff.

The second bug you linked seems spot on.

A few points to make clear:

1. All of us in the team have this issue and we are using a wide set of different computers so It's very likely not related to any hardware.

2. Given the info in the bug you linked this can be reproduced in most versions from 2019.4 (perhaps even .3) and above. Those explicitly not stated in the bug are probably just not tested.

3. It can be reproduced with a simple sample scene.

Given that these are the case, most ppl using 2019.4 or later should experience this, and in my opinion this is quite a big issue. Not being able to inspect the values of a game object while playing (and remaining sane) seems like a pretty basic feature one should expect from the editor.

So how come this issue is not actively being addressed by the developers?

 

Right, well if you look at the bug it states that given a scene with only a simple cube the framerate is vastly different in play mode when that object gets selected (and visible in the inspector). It mentions an attached file which I can't find but I'll set up the same scene later today my self to se if I get the same result.

If this is indeed the case and then most likely not unique for cubes I don't really see how anyone can create a scene in which this is not the case.

I'll investigate and get back to you.

 

So I spent last evening digging into this and the findings was actually a bit unexpected. I'm afraid I have to take back parts of my statements.

First off all the bug which was linked in which it was stated that a single cube being selected did should cause severe reduction of fps was not the case for me or my team. So based on that I clearly agree that this is not anything anyone would experience all the time.

However in our game, objects that had lots of updated values did cause a 80% drop in fps when being selected so I started disabling components to try to figure out what caused the issue. It turned out that having a SINGLE component which was modified to only slightly update the x position of the object was sufficient to cause the issue. I even removed all custom components (non unity ones) and the issue was still there. However, when I removed the AudioSource the issue went away. It turns out that having an AudioSource on the object and updating the position was the secret sauce that caused the issue. I solved it by simply putting the AudioSources on child objects instead. I haven't tried this in pure isolation (the cube sample) but plan on doing it. I'll get back with the results.

 

I ran into similar issue when I have a GameObject with an Audio Source Component selected in the editor. Went from ~3ms to ~11ms. Problem occurs when the audio plays. I'm currently using Unity 2020.2.2f1

 

I am currently using latest 2019 lts update and I encounter this problem as well. My fps drops from 150 to 50 fps when I inspect an object that has an audio source component attached. I am not using that component/referencing it any way and the object doesn't matter if it's moving or not.

 

Hi, I necro this thread because I have exactly the same thing. Fun fact, the object I look at the inspector is a prefab, so no updates. It happen only when the rigidbody info section is open. The performance drop is significant, from 110FPS to 25 FPS. I'm using unity 2021.1.5f1. Is there any fix in sight?

 

Might work for some, but not for most. Unity 2021.2

Yesterday, I had a similar issue pop up and my CPU jumped from the normal average of 25% to 90% on the editor for the renderer in play and I didn't change anything between the previous play and the play that started the issue. Did the standard reboot and this and that. Every time I open and hit play from that point forward, all 8 cores on my pc are screaming. Had a few times where it would run out of ram and lock up too. The flow was stop playing and hit play without anything changing between and it got whacked with something.

Setting the flag in Hub

-force-gfx-direct

Took it back down by loading everything on one thread. This works pretty well so far. There is no noticeable lag in gameplay in play mode, but I'm only in 2D with a 500x500 tilemap and whatnot. So, not exactly intensive. It might work for a few folks as a work around for now.

Keep up the good work Melvmay!

 

In my case, closing the very bottom of the audio info ( graph area ) stopped the FPS drop, but selecting the gameobject containing audio still causes FPS drop but only about 10-20%. Deleting the audio component entirely gives an FPS boost of about 50%.