Feedback (Case 1211383) Some Editor Overhead in Playmode debunked

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.

Spoiler: Holding no Key, Mouse moving in GameView

Spoiler: Holding A, Mouse moving in GameView

Spoiler: 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.

Spoiler: Video

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.

 

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

 

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!

Spoiler

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

 

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

Nice job Peter!

 

Dev's parents:

 

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

 

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...

 

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


Whoever this was: Touché

 

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.

 

This is possibly the greatest forum thread of all time.

 

QA was able to reproduce the issue and found it's a regression introduced in Unity 2019.3.0a2.
https://issuetracker.unity3d.com/is...g-down-keys-and-moving-mouse-when-in-playmode

Spoiler: Thank you!

 

Amazing

It's the least you deserve for submitting all these reports though...

 

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.

 

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.

Spoiler: Profiler screencap showing EditorLoop cost

 

That sounds very nice!

 

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

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.

 

Just more of EditorLoop, 30 ms.

I'll test later at home with 2018.3.

 

Tested it with 2018.3.14f1, there is still EditorLoop there (what does it do that is updated every frame without any input?), but it is only 2.7 ms instead of ~8. It is an inconvenience when testing VR in the editor.

Spoiler: 2018.3 profiler

 

Oops, I had others disabled in that picture yes. Using editor profiling the origin of the spikes is solved: it is the profiler being updated.

Still, in 2019.3.0f3, an empty scene and no windows open (other than Game and Profiler) I'm getting results like this:

Spoiler: Editor profiling

So 8.61 milliseconds, not counting the profiler updating the graph.

 

OOPP is already available in a20? How do we use it?
That's huge!

Also, great work nailing down those ms. They really add up and I know we've all lost countless hours due to them.
The editor perf improvements are my favorite part of the release notes and I'm always looking forward to seeing more and more of them. Many of us are, for sure.

 

What is OOPP?

I like the idea of profile markers, that's gonna help a lot

 

Thank you and the team for not taking the bug-report lightly. I'm looking forward to an update where I can test the improvements.

 

Excellent news, Leonhard. Thanks for the update!

 

When reading the first post it looks like a similar problem I reported (1249910), but if it really was fixed, then it probably wasn't. The editor lags/buffers input (while playing or not) if a keyboard button is pressed and the mouse moves. The lag can grow to several seconds and can easily be reproduced by:
- Create a new empty project, and set vsync to 30 fps (only needed for beefy computers).
- Create a script that does something while a key is pressed. For example:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class MoveIfPressed : MonoBehaviour {
4.     public KeyCode key = KeyCode.Space;
5.     void Update() {
6.         if (Input.GetKey(key)) transform.position = Random.onUnitSphere;
7.     }
8. }

- Add the script to a cube, point a camera to it.
- Have both the Scene View and the Game View opened. Open the profiler and set it to record mode. Hit play.
- Now keep the key pressed and move the mouse around on the game window. After some seconds, release the key.

The cube should keep moving after the key is released.

This problem seems to happen if the scene view and game view are opened and some window, like the profiler, is doing something, but I had this problem even with the game view maximized (but now I can't reproduce it).

 

@jonathans42
I'm seeing this issue still happening in the recently released Unity 2019.4 LTS...

 

OMG! Dude, Thank you! This is exactly what I was experiencing! I hope they do something about it or at least release a statement.
I also wanted to add that this "bug" or whatever especially hits performance when my laptop in powersaving mode (I think it's downthrottling under light loads and then FPS drops to like 15 when you hold keys) this issue however goes away when I start to watch some videos in the background (maybe laptop throttles back up). Really strange behavior.

 

I believe part of their fix is the new "Interaction Mode". Once I set this from "No Throttling" to "Monitor Refresh Rate", everything is faster. However, I'm not sure if that exists in 2019.4, I believe it's available in 2020.1 and newer only.

 

2019.4 has it too.