Hi
Just upgraded my project from 2020.1.4f1 to 2020.2.0b1 to test it out… and i noticed overall massive FPS drop (~52% down; 350fps to 165fps)
I tested out the default URP project (the example project). same performance drop (~62% down; 450fps to 170fps)
Is there a new expensive Quality option or something? i dont see any noticeable visual difference
Thanks.
Does the Unity profiler show where the time is being spent?
Noticed this as well. According to the profiler, most of the perf hit is in Scene view and Game view’s UIRepaint. But PlayerLoop is also down roughly 15% perf in my case. And yeah, total Playmode Editor performance seems to be halved compared to 2020.1.0f1.
I had a look at URP default scene performance in 2020.1 and 2020.2 on my Mac and was unable to reproduce this regression.
Could you please try to capture and compare profiling samples with the Profile Analyzer to check where the differences stem from?
In both versions of the project (2020.1 and 2020.2)
Once both samples are saved
This will give you the processes with the largest deviation in frame time between the two samples. Once you have this information, please share your findings here.
Done. This is captured on two new projects with the URP default scene. “capture1” is Unity 2020.1.0f1. “capture2” is Unity 2020.2.0b1.2959. I’m on Windows and have dual Monitor setup (if that matters). Both Scene view and Game view are visible during profiling.
It seems like some major regression in UIElements.
UPDATE:
I’ll also include the capture data (both regular and deep profile):
https://drive.google.com/file/d/111c4rRPmSnDkFDm2m5qYdOOXk_QiOqUG/view
here is the captured data if it helps
https://drive.google.com/file/d/15ncfwqBPBX8VvjV9b8WnVthr0L_KHLA9/view
The Profiler Window getting repainted in some of those frames is skewering the data somewhat. To mittigate that and actually find the difference in the normal frames, you can right-click the charts in Profile Analyzer and order the frames by duration. Then select a range that is excluding those high spikes which would be pushed to the right side by this ordering. This way you can compare the average frames in both unity versions without the frames in which the Profiler gets repainted.
The alternative solution would be to capture the data with the F9 shortcut to start and stop profiling while the Profiler Window is closed so it doesn’t even get captured in the profiler data.
Wouldn’t the best thing just be to run the profiler as a standalone process? That should minimize the interference, right?
Any Unity folks (or anyone besides me and @DrabanL ) able to reproduce this on their side now (on Windows)?
Im not sure why you asked for Editor profiling.
This are the result i get when targeting Playmode (the performance reduction i experience is in playmode)
(deep profile, “order frames by duration”)
and here is link for all profiling data: https://drive.google.com/file/d/1o_okzZEMsfrmPNpeet53BXWwzTplwTrk/view
I’m suspecting it’s an issue in EditorLoop which affects all Editor UI including Scene view and Game view. You can try this:
In 2020.2.0b1, have both Scene view and Game view visible during Playmode. Then while the game is playing, close the Scene view tab. Do you notice a considerable FPS bump? In my case, in an empty scene, the FPS roughly doubled.
In 2020.1, opening and closing the Scene view would not have such noticeable effect (in an empty scene at least).
(by empty scene, I mean just a newly created scene with a default Main Camera and Directional Light)
@Singtaa well, there is a drop using the steps you described.
but, what i experience is preset even if the Scene window is completely closed.
hence i think there is another or additional issue to what you mentioned.
here is more obvious example, of completely empty scene, in play more, while Scene window is closed.
2020.2.0b1
2020.1.4f1
250 fps vs 1000 fps
insane!!
Same issue with 2020.2.0b2
Could both of you please submit a bug report for this? No need for a reproduction project if this happens in the URP default scene. We need to have a look at your system specs and set up in order to investigate this. The bug reporter automatically grabs this information.
Sure, done. Case 1277222
Also, I tried on b2 that just came out, problem still persists.
I’m seeing this also. Ms went from 3.2 in 2020.1 to 5.2 in 2020.2.
Good news, we were able to reproduce the issue. You can check its resolution status here. Thanks to everyone in here for bringing this to our attention and special thanks to @Singtaa for submitting the bug report.
In 2020.2 we’ve changed the way how Rendering stats are collected. At the same time we fixed a couple of counting issues for Draw stats. And we also aligned the “main thread” time values (as well as FPS) with a real timings game has in the Editor. The time/fps estimation based only on game activity doesn’t actually represent time in Player builds and is not consistent with actual frame rate you can obtain with system tools - this was a source of confusion and overpromising since 2012 
We are updating manual page to reflect the latest behavior.
If this is the only reason behind the performance regression I would consider it as a bug only if you still want to see the estimated game-only fps in the stats overlay and want this to be communicated better in the overlay itself.
Please note that, as I’ve outlined here , that such guesswork would currently require serious hand waving on any game that is rendering, GPU or VSync bound.
And yes, that guesswork is what is currently in the game stats view. Just upholding that as the Status Quo seemed less desirable than fixing it to a non-guesswork measurement that includes editor overhead though.
