(Case 1211383) Some Editor Overhead in Playmode debunked

[Peter77]

I believe I made an interesting observation that hopefully helps to solve some of the existing editor overhead performance problems during play mode, which often cause my game to become very laggy and sometimes almost unplayable in the editor ( eg this ).

I observed Unity adds a significant processing cost while holding down keys.
Some key combinations cause the editor performance to drop significantly.
In a first person shooter you navigate through the world via WASD-keys and SHIFT-key to run, which causes the editor to drop performance significantly, just because of holding these keys.

The performance drop depends on the window the mouse pointer is located.
The performance drop is significantly worse while the mouse is over the Hierarchy window than the Game window for example. When testing/playing in the editor, the mouse very often ends up or moves over the hierarchy window.

Holding no Key, Mouse moving in GameView

Holding A, Mouse moving in GameView

Holding Shift+A, Mouse moving in Hierarchy

I’ve recorded a rather lengthy video where I go over these findings, which hopefully helps you to solve these performance drop issues.
Video

https://www.youtube.com/watch?v=8c5mFkz96H8

Please note that in this test there is no actual game running. It’s an empty project. In a real project, you actually have your 30ms (or whatever) spend on the game. If another 30ms kicks in just for editor keystroke processing, this gets unplayable quickly.

Reproduce

• Open attached project
• Open SampleScene
• Open from main menu “Window > Analysis > Profiler”
• Switch Profiler to Editor mode and start recording
• Press Play
• Hold down “A” key and observe performance in Profiler
• Hold down “Shift+A” key and observe performance in Profiler
• Hold down “Shift+A” key while moving the mouse over the Hierarchy and observe performance in Profiler

Actual
Holding down keys cause a huge performance drop.

Expected
No performance drop.

[DoctorShinobi]

When I was a child my grandfather used to tell me stories about Peter77. He said the common folk called him “QA Jesus” back in the day and that he was feared by all programmers in the west.

Congrats on yet another detailed performance bug report

[Peter77]

QA Jesus, LOL!

I guess inside Unity Technologies it’s more likely they refer to me as “oh no, not him again” ;), even though I have no ill intentions. Really!

Just kidding, I know Unity staff appreciate my reports, they told me on various occasions.

[rastlin]

I imagine, at UT, people meeting in kitchen for coffee or something and chatting:

• Hi, how’s going, any plans for Christmas?
• Doing great. We plan to have big family dinner, I’m finally gonna meet with my far far uncle after 10 years!
  
• Guys, guys, it’s terrible!
• What?!
• Don’t tell me it’s…
• Yes, Petter77 posted another performance regression!
  
• Eh… I need to contact my parents and tell them, I’m not coming back for Christmas .

Nice job Peter!

[DoctorShinobi]

@rastlin

I imagine, at UT, people meeting in kitchen for coffee or something and chatting:

• Hi, how’s going, any plans for Christmas?
• Doing great. We plan to have big family dinner, I’m finally gonna meet with my far far uncle after 10 years!
  
• Guys, guys, it’s terrible!
• What?!
• Don’t tell me it’s…
• Yes, Petter77 posted another performance regression!
  
• Eh… I need to contact my parents and tell them, I’m not coming back for Christmas .

Nice job Peter!

Dev’s parents:

[Neto_Kokku]

You’re not a good QA until developers flinch and recoil when they hear your name.

[Metron]

@Peter77

I believe made an interesting observation that hopefully helps to solve some of the existing editor overhead performance problems during play mode, which often cause my game to become very laggy and sometimes almost unplayable in the editor ( eg this ).

I observed Unity adds a significant processing cost while holding down keys.
Some key combinations cause the editor performance to drop significantly.
In a first person shooter you navigate through the world via WASD-keys and SHIFT-key to run, which causes the editor to drop performance significantly, just because of holding these keys.

The performance drop depends on the window the mouse pointer is located.
The performance drop is significantly worse while the mouse is over the Hierarchy window than the Game window for example. When testing/playing in the editor, the mouse very often ends up or moves over the hierarchy window.

Holding no Key, Mouse moving in GameView

Holding A, Mouse moving in GameView

Holding Shift+A, Mouse moving in Hierarchy

I’ve recorded a rather lengthy video where I go over these findings, which hopefully helps you to solve these performance drop issues.
Video

https://www.youtube.com/watch?v=8c5mFkz96H8

Please note that in this test there is no actual game running. It’s an empty project. In a real project, you actually have your 30ms (or whatever) spend on the game. If another 30ms kicks in just for editor keystroke processing, this gets unplayable quickly.

Reproduce

• Open attached project
• Open SampleScene
• Open from main menu “Window > Analysis > Profiler”
• Switch Profiler to Editor mode and start recording
• Press Play
• Hold down “A” key and observe performance in Profiler
• Hold down “Shift+A” key and observe performance in Profiler
• Hold down “Shift+A” key while moving the mouse over the Hierarchy and observe performance in Profiler

Actual
Holding down keys cause a huge performance drop.

Expected
No performance drop.

Is this also happening when you hover the inspector window? It might be possible that the performance drop induced by moving the mouse button is the result of highlighting an entry in the hierarchy…

[Peter77]

@DoctorShinobi

common folk called him “QA Jesus”

Holy Moly! They just turned me into QA Jesus for real…

Whoever this was: Touché

[Peter77]

@Metron

Is this also happening when you hover the inspector window?

The performance impact while holding A, while the mouse pointer is over an empty Inspector window, is the same as when the mouse is over the Game View.

If there is an object assigned to the Inspector, it shows the same “base cost” for the additional key processing.

In addition to that, whenever the mouse moves over an UI Inspector element that has a hover state, it triggers a repaint, which is expensive. Perhaps that’s also the problem with the Hierarchy.

[Incode]

@Peter77

Holy Moly! They just turned me into QA Jesus for real…

This is possibly the greatest forum thread of all time.

[Peter77]

QA was able to reproduce the issue and found it’s a regression introduced in Unity 2019.3.0a2.

Unity IssueTracker - Editor performance drop when holding down keys and...

Thank you!

[jdtec]

@Peter77

Holy Moly! They just turned me into QA Jesus for real…

Amazing

It’s the least you deserve for submitting all these reports though…

[Bordeaux_Fox]

So everytime I call the Unity Input class, I get these spikes in my game? Is it just in the editor playmode or also in build?

[Peter77]

@Bordeaux_Fox

So everytime I call the Unity Input class, I get these spikes in my game? Is it just in the editor playmode or also in build?

No, that shouldn’t be the case, or it’s at least not what I observed.

The spikes seem to be related to the editor only.
I have not seen this in a build.
The Input API does not seem to play a role in this.

[tspk91]

Woah, this is actually happening. In our project it turns 55 fps to 30!

The perf impact really varies from key to key, taking as a reference Control and Alt: Enter causes 2x the spike, and Shift actually doesn’t cause any.

Tthe editor still has huge overhead in play mode, even when no input is present and with the GPU almost idling. It even has a “heartbeat”. Gonna have to post a ticket.Profiler screencap showing EditorLoop cost

[karl_jones]

@tspk91

Woah, this is actually happening. In our project it turns 55 fps to 30!

The perf impact really varies from key to key, taking as a reference Control and Alt: Enter causes 2x the spike, and Shift actually doesn’t cause any.

PS: the editor still has huge overhead in play mode, even when no input is present and with the GPU almost idling. It even has a “heartbeat”. Gonna have to post a ticket.

Hi, we are looking into these issues.
The heartbeat is the profiler window, it only updates every 5 frames for performance reasons.
Part of the issue in 2019.3 is the profiler window itself, if you hold down A it then shows the timeline view which has a higher perf cost. We are looking into changing this default Key.
We are also developing an Out Of Process Profiler which will let you capture without the overhead of the profiler itself in the results.

If you want to compare between versions then the Profile Analyzer is a very good tool to do this https://blogs.unity3d.com/2019/05/13/introducing-the-profile-analyzer/

[SugoiDev]

@karl_jones

We are also developing an Out Of Process Profiler which will let you capture without the overhead of the profiler itself in the results.

That sounds very nice!

[tspk91]

@karl_jones

The heartbeat is the profiler window, it only updates every 5 frames for performance reasons.

In my computer the interval seems to be 67 frames in an empty scene.

@karl_jones

Part of the issue in 2019.3 is the profiler window itself, if you hold down A it then shows the timeline view which has a higher perf cost. We are looking into changing this default Key.

Testing an empty scene just with a FPS counter (not even a camera), EditorLoop still eats 7.5 ms when the only open window is Game. I haven’t noticed the profiler making much of a difference, does it always run in the background?

PS: this is with 2019.3.0f3.

[karl_jones]

@tspk91

In my computer the interval seems to be 67 frames in an empty scene.

It could be something else. Just look in the profiler and it will show you what is happening in the spike.

@tspk91

Testing an empty scene just with a FPS counter (not even a camera), EditorLoop still eats 7.5 ms when the only open window is Game.

How much did it use for you in previous unity versions?

@tspk91

I haven’t noticed the profiler making much of a difference, does it always run in the background?

No, it only runs in the background if its enabled via the editor or a script.

[tspk91]

@karl_jones

It could be something else. Just look in the profiler and it will show you what is happening in the spike.

Just more of EditorLoop, 30 ms.

@karl_jones

How much did it use for you in previous unity versions?

I’ll test later at home with 2018.3.