Bug Inspector causes extreme lag in play mode

I am trying to solve this since weeks, googling every single day, I think I tried everything and nothing works.

When I start the game with the inspector visible, it can be any inspector, it just needs a lot of fields drawn, all inputs are delayed for up to 10 full seconds.
Example: I am running around in my scene, take the hands off my keyboard and the player keeps running and moving the mouse with a delay of up to 10 seconds.
While playing, I can press left for a couple seconds, then press and hold right - player continues to go left for <10s then proceeds to go right. It's just a enormous lag.
The editor does not freeze completely but it ignores (or stacks?) new inputs while rendering the game view at a low framerate (despite the "Stats" showing 200+ fps).

The input is from the original Standard Assets FPS controller, nothing was changed, not the inputs, not the controls or anything.
Profiling the Editor with the Profiler, showed me that the Inspector keeps drawing itself for about 1000 times a frame, causing massive loads of garbage which will also be collected in the very same frame, resulting in extreme lag.
If I hide the Inspector ("Maximise on Play" or just closing it) or select another GameObject with less fields to draw, everything behaves as it should.

Profiler attached to the Editor showed tons of "Material.SetPassFast", "GC.Alloc", "EditorGUIUtility.HandleControlID()", "GUITexture.Draw", "Transform.GetScene" calls in about 30-40 individual calls of "UIR.ImmediateRenderer".

As said, it can be ANY inspector - not using any kind of custom inspector here.

So what I tried:
1) Completely uninstalling and reinstalling Unity+VisualStudio.
2) Using another mouse, because I read it could have something to do with the mouse poll rate.
3) Having the GameView in the same Window as Unity (usually it is on my second monitor).
4) Deactivating other monitors.
5) Unplugging USB xbox controller.
6) Updating all drivers and windows.
7) Checking every single setting in preferences and project settings.
8) Deleting the libary folder.
9) Backup my project and deleting 80% of the 40GB files, including Odin, Peek, Rainbow Folders - the lag was still there, so it is none of the custom tools.
10) Resetting to default layout.
11) Checking every BIOS Setting, excluding Unity from Windows Defender, deactivating almost everything except for unity (task manager, services, autostart, cortana, everything).
12) Sending the whole project over to a friend - it runs fine on his machine .. after 4h in discord he was still not able to reproduce the lag.
13) Deactivating Preferences/General/AutoRefresh, setting Preferences/General/InteractionMode to every available Option.
14) Running the Editor with Unity.exe" -force-opengl, this caused some funny artifacts so I knew it was running, but the lag was still there.

I have no idea how to solve this. As Programmer I have to watch variables in the inspector while the play mode is running, hiding the inspector is not an option for me.

Any ideas? I am 99% sure reinstalling windows won't solve the problem and would just be a huge waste of time.

Unity Version: 2019.3.12f1 (also tested with 2019.3.6f1)

Hardware:
Processor
Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz

RAM
32 GB

Video Card
NVIDIA GeForce GTX 980 Ti

Operating System
Windows 10, 64-bit

Drive
SSD Corsair Force Series MP510 960GB

 

Reinstalled Windows completely clean on a new hard drive - only installed Firefox & Unity, still have the same Lag.

How? Why? The friend from "12)" has the same hard drive, so it can only be the CPU, RAM or GPU causing this error.

I am using unity since 4.x, since more than 6 years and never had such issues.
It could have something to do with the new UI Elements - I just don't understand how this is a Hardware related problem...
That just doesn't make any sense.. where does the Editor UI update come from?
Any kind of insight would be awesome.

 

Are you storing large amounts of data in a scriptable Object? That did it to me. (16 MB) If I had the scriptable object selected in editor, everything slowed to a crawl.

 

I don't have any SOs or gameobjects with lots of stored data in the project, also I can select any Objekt with lots of fields in the inspector to trigger the lag, it's no difference between one monobehaviuor with 20 fields or 10 monobehaviuors with 2 fields each.

Also checked the editor log, there are no errors, it is just refreshing the inspector too often or maybe adding Elements to the rootVisualElement without removing them?
If I knew more about the refresh rate I could atleast understand why this is happening.

The old imGUI had a refresh rate of 10 times per second

 

Today I changed the whole project to use the new Input System, now I can control the Player slightly better because inputs do not get stacked that much. IDK why.
Also I used the EditorUI Debugger - seems like the Inspector is still drawn using IMGUI, wrapped in UI Elements - once this changes and everything is drawn with UI Elements, I hope that my lag will be gone.

But I'd really like to know whats causing this ... for a non-engine programmer like me, it looks like some kind of double-loop "foreach element { foreach element {Draw()} }" - so all elements are drawn for each element in the list, exponential performance loss maybe based on the draw-rate of the Screen? GPU? I have no idea. Thats just a wild guess of course.

 

I have custom inspectors ... I upgraded my project from 2019 to 2020, and now the game freezes up and eventually crashes out if I select a gameobject with those while the game is running. It keeps giving me hold on bars over and over so long as the object is selected. It did NOT do this in the last version of Unity.

So they definitely made a change that effectively broke stuff for debugging during play mode. Considering it worked fine in last year's editors, I doubt its because I'm doing anything horrible. I am using the IMGUI editor stuff, but thats supposed to still work. So very dissapointed in this behaviour which came out of nowhere, as its destroyed my ability to easily debug the game without redoing a bunch of stuff or understanding whats wrong/if theyll fix it.

Why should Application.Tick be running for 4minutes straight now without ever stopping? Sigh. The only way out at this point is to end the task and reopen Unity, which I have to do basically any time I accidently click on the wrong game objects now, let alone being able to tell what their data is anymore.

 

I'm having the same problem.

Any progress on finding a solution?

Did you report an actual bug to Unity?

Can we have a comment from Unity on this?

 

I'm also having significant lag spikes in play mode when certain monobehaviour objects are selected in the inspector. Profiler shows same as OP, inspector rendering causes immense garbage collection which is causing the spikes. And it happens only when I'm inputting movement and the values in the inspector change. If I deselect the object and inspector is rendering nothing, the spikes stop.

I am still using the old input system. And am also not using custom inspectors on many of the objects the problem occurs with.

 

I found the cause in my project. It may or may not apply to yours.

Solution

The Info sections of Rigidbody 2D, Circle Collider 2D, etc. seem to be the culprits. Folding them resolves the issue.

Study

First, I checked Profiler info by unfolding UIR.ImmediateRenderer (I have only one call on my machine). It showed me a few components' Editor.[Component].OnInspectorGUI calls with their times. But, it turned out those individual times were not correlated to the tremendous lag added by some component rendering in the Inspector. You can verify this by folding/unfolding the components.

For instance, the profiler showed that out of 35ms of UIR.ImmediateRenderer, Rigidbody 2D took 4.7ms, Sprite Renderer took 3.9ms and Circle Collider 2D took 2.6ms. However most of the time was still on UIR.ImmediateRenderer internal time itself (not calling other named methods), and testing showed that:
- selecting the game object with Rigidbody 2D OR Circle Collider 2D component pane unfolded will drop FPS from 60 to under 30
- selecting the game object with the two components above closed, and other components (including Sprite Renderer) open, will not drop FPS

In other words, the real issue is not with the component rendering code, but with the call to UIR.ImmediateRenderer itself. Or rather, its indirect parent InspectorWindow.Repaint.

Since only Rigidbody 2D and Circle Collider 2D had the issue, I looked for a common point and found that both had an Info section that shows realtime read-only information while playing. It turns out that folding just the Info sections fixed the issue and I got my 60 FPS back in the Editor (unlike the OP, Stats did reflect the lag and showed low FPS to match the perceived FPS in the editor).

Interestingly, folding just the Rigidbody 2D and Circle Collider 2D components without folding their Info components will keep reducing FPS until you actually unselect the game objects. When you select them again with either component or the Info sections folded, the high FPS are preserved. I guess this is because as soon as you display the Info section once, the Editor tries to update them even if the component is later folded. Folding the Info section itself however, will always prevent it from updating and stop the lag.

I did some more tests such as:
- without playing the game, open the Info sections. You cannot pereceive lag and the Stats FPS do not change if you do that, but interestingly the Editor Profiler will show that you're now spamming InspectorWindow.Repaint.
- while profiling, unfold Info section and fold it back. Stop profiling. Click on a frame while Info section was unfolded. Observe the expensive UIR.ImmediateRenderer, click on it to get focus. Then click on another frame in the Profiler where Info section was folded. UIR.ImmediateRenderer, and actually the whole call tree up to InspectorWindow.Repaint. is now absent, so selection moves back up to the next parent GUIView.RepaintAll.PlayerLoopController. In other words, InspectorWindow.Repaint cost was so negligible (or it wasn't called) that it's normally completely skipped by the profiler
- as a comparison, I selected an object that is simply moving, so the Transform component view needs to get updated. This wasn't enough to show InspectorWindow.Repaint in the profiler
- as further comparison, I manually dragged a component value (e.g. Rigidbody 2D Mass) and shaked my mouse like crazy to modify the value very frequently. It did show InspectorWindow.Repaint in the profiler, and showed visible FPS drop (under 30)
- I checked memory and also get incredible memory increase when not playing the game, just showing the Info section. Maybe some garbage created either by Inspector Repaint in general, or the Info section in particular. When playing the game, memory increases regularly anyway, so I couldn't really compare.

Conclusion

My conclusion is that the Info section of Rigidbody 2D component, and others, requires continuous update of the Inspector (even if not playing game!), spamming InspectorWindow.Repaint calls, which may be more or less complex depending on how many components you have; but even if you have few of them, the regular update increases CPU a lot and shows visible lag.

It must also register the need update even if you fold the component (until you unselect the object), so you'd rather fold the Info section itself each time.

I'll file a bug report, hoping they can do something about it. We'll still need the update of the Info section, but maybe we don't need to update the whole Inspector every time.

 

I sent the bug report.

 

Yes, I caught the fact it was asking the editor to repaint repeatedly; but that may be required to get regular updates, so maybe the issue lies in how it's done.

For people following this thread and others just arriving here, I'll give the link to the issue which is now public:
https://issuetracker.unity3d.com/is...ody-2d-or-other-2d-physics-components-is-open

 

I first noticed it after updating to either 2017.1 or 2018.1 I can't remember which, and have since hoped it would improve over time but I think it has gotten worse with each new unity version. I have to have nothing selected in the inspector during playmode in order to not get consistent spikes below 60 fps even in a barebones scene. I still feel like there must be something I'm doing on my end to make it worse because from unity 4.6 to 2018 I never had any editor slowdowns, but I started messing with custom editor/inspector scripts around when the slowdown started, but even with all my custom editor scripts disabled it still happens, so I'm not sure. Hopefully they can improve it.

 

Hm, they just marked it as Won't Fix. Check the public issue link for more explanations.
You think it's worth asking them to at least show a warning message to users that FPS may drop down? or just wait for the possible optimization with the new UI Toolkit inspector?

 

I could fix input lags in scene and game view by logging in again in Unity Hub

 

Just stumbled across the topic.
In my case, it was package "Version Control" 1.14.9.
It has added "Plastic SCM" to the editor, which added a button to the main editor GUI, which was subscribed to any keyboard input, and tried to update its icon every time the keyboard was pressed, which was causing 50ms lag.
Someone should definitely report the issue, I just removed the package.
Cheers.

 

I got from Unity 5.3.1f1 to Unity 2017 and my project started lagging so bad specially in Play Mode. If your project is lagging, try reverting the Windows Layout or just use a different one. As of this moment, my 2017 project is running perfectly without lags ( Graphics Stats kicking at 12.3ms )

Before, I played the previous 5.3.1f1 project and 2017 converted project in the same laptop and 5.3.1f1 is doing it better, with 2017 suffering so bad.

I also noticed the settings I did on terrains are modified upon transfer to 2017.

Do note this is only for Editor Lagging Fix, not for the build.

 

Collapse the Transform component in the Inspector of selected game object fix this issue for me.