Bug (Case 1203866) Performance issue with EditorLoop

looks to me like you have Game and Scene view open at the same time. So basically the same content needs to be displayed twice, from two different perspectives, all with the entire view and it's buttons and settings needing to be processed. If you dock Game and Scene view into the same docking area of the editor, so you'll only ever see one, you'll get better performance during Playmode.

Those spikes on the other hand very much look like the Profiler Window getting repainted every couple of frames. To take those out of the equation, we introduced the Menu option Analysis -> Profiler (Standalone Process). That is not just a bandaid for bad performance of the Profiler Editor Window performance either, we are constantly working to make the Profiler Window impact to be lower (more performant, profiling costs less intrusive), but more a way to avoid recursively deep profiling the Profiler Window itself when targeting the Editor, too.

You can also Profile data with the window closed (it will continue gathering data in the background), hitting F9 (Shortcut introduced in 2019.3 to toggle Recording state) or by profiling to file using Profiler.logFile .enableBinaryLog and .enable (example in the link).

Finally, separating the Playmode execution from the surrounding Editor is currently nigh impossible but efforts like LiveLink aim to eventually offer similar iteration speeds while separating Player and Editor executions more fully. Until then (and probably even with it, though less so), the best way to check the performance you'll have finally is to make a build and run it on your target platform, attaching the Profiler to it for details. Find issues this way, then profile in the editor with the methods described above for better iteration workflows, but take all data with a grain of salt and staying focused on what you discovered in the build.

Also, @Peter77 's advice on the Interaction mode and @MasoInar 's hint on the game view's vSync setting could also be beneficial to follow up on.

 

Also, the issue found on our side in investigating the bug report was related to EditorStyles.UpdateSkinCache and fixed as a 2019.3 regression. Overall the performance of this scenario doesn't seem to have changed much beyond that regression over the last Unity versions (back to 2017.4), even if the public info on that bug report is admittedly not great and a bit confusing on that topic...

 

Did you try setting it to anything else and fiddle with the Custom delay?
It could be you are encountering a genuine bug there that needs your Project, some Editor code in it or specific hardware to trigger. In that case it'd be super valuable to us if you could file a bug report so that we can address that, because it's obviously not ideal and not in our interest to have an LTS version regress in performance like that and essentially forcing people like you to downgrade (or revert the upgrade back to) to a 2 year old LTS that is about to laps out of the 2 year support window.

If it is something that specific that we're not aware of, not having any bug reports on that would mean this might not get fixed until you're eventually forced to update (because e.g. that support window runs out and you are facing blocking issues or need a newer platform SDKs...) so it is likely not in your best interest not to report this either...

@YuriyVotintsev did you try the Custom option and tried different values? Cause that kinda refresh rate would try to push a new editor frame every 0.006ms which would essentially be the same as No Throttling...

Update: sorry, my math brain failed me on this one. That'd be 6ms and still having a throttling effect... Still worth exploring the Custom option to see what happens.

 

Thanks, I looked over the report. The Spikes you encountered in an Empty Project look very much like the Profiler Window itself getting repainted, which doesn't sound like your original problem at all.

yeah, sadly that's a pretty pointless endeavor as this is way to vague and could caused be any number of things. EditorLoop is just a black box until to toggle on Profile Editor (in Unity versions pre-2019.3) or since 2019.3, change the Profiler Target from "Playmode" to "Editor". Believe me, I know this is confusing and frustrating, even our QA sometimes falls into that trap (which is why your bug got falsely attributed as a duplicate. I detached it again and am working it out with our testers).

Further ways to get closer to the root causes of such behavior is to use the Standalone Profiler available in 2020.1 or it's less fortunately named, WIP predecessor "Out-Of Process" profiler, that is already available in 2019.3 if you switch to internal mode.

Please Make a backup before following these steps and be sure to exit internal mode again before you leave the Editor!

1. Go to

   Help->About Unity

   and type "internal" with that window in focus (repeating the same exits internal mode again)
   
2. Go to the Preferences, find the Profiler settings
3. toggle on "Out Of Process Profiler (experimental)"
4. close Profiler Window if open
5. Hit CTRL/CMD +7 or open the Profiler regularly:
6. -> Same thing as the Standalone Profiler, just an uglier name

You can technically exit internal mode while using the Standalone Profiler be repeating step 1. However, I'd advise you to disable the "Out Of Process Profiler (experimental)" option and exiting internal mode before closing the Editor. Or if this crashes (it is internal/experimental for a reason after all), reopen the project first, uncheck the option and exit internal mode again, before opening any other project or editor version.

that is very fair. However, I hope that this information on how to profile the Editor may come in handy to you or anyone else at some point now or later though.

 

Alternatively you can also avoid the Profiler Window overhead by keeping it closed and starting and stopping the Profiler with the F9 shortcut to toggle recording, then open the profiler.