2020.2.0b1 Performance Reduction

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?

 

(URP default sample project)

 

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.

 

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

 

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)

 

@Creepgin 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

 

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.

 

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.

 

Thanks guys for the feedback!

Yes, that's reasonable. However, I don't think it's just the stats overlay. All my profiling did show a major slow down on the EditorLoop (when compared to 2020.1). Or are you saying we can ignore this and this may be the new norm going forward?

Also because @LeonhardP wasn't able to reproduce on his end initially, I got the feeling that Mac wasn't affected?

 

I can confirm that performance of the actual build project is pretty much the same as 2020.1 (1% or 2% percent lower, but thats fine)

however, like already discussed, when working with the editor performance are massively degraded (tested with external FPS counter as well)

this reflects on workflow considerably..

 

If you don't have to debug scripts, you should always make sure that unity is running in release mode (if not already active).

 

One thing I noticed in the past version (from 2019.3?) is that playmode is only smooth when using it in fullscreen. There is now a new "Interaction Mode" option in editor preferences, which I set to "Monitor Refresh Rate" but it doesn't have any effects on playmode as stated in the docs:

https://docs.unity3d.com/Manual/Preferences.html

 

Not exactly. The way how FPS number in stats panel is calculated is one question (and I mentioned this in the discussion to highlight the need of using profiler captures for objective analysis).
But another one is Unity performance in the Editor - many teams are working on performance and workflow improvements in the area and we definitely don't want slower Editor to be a new norm
As @LeonhardP mention, the bug is being investigated and profiler captures + system data are very useful, thank you for the help!

 

many versions later (including alpha)

still the same... AND issue flagged as "Not Reproducible" in tracker

 

I also recently tried the newest 2020.2 beta and performance was much worse than 2020.1.

 

Not sure what's going on with the "Not Reproducible" status. Like @DrabanL said, the issue is present in all the 2020.2 beta releases so far and is even present in 2021.1.

In general, 2020.2 still have some major Editor performance issues across the board, and not just with URP either.

 

unfortunately it looks like they are unable to "fix" the performance degradation in Editor.
most likely a mod or a new feature that was introduced along the way was the cause of it, in which they would need to make a choice of either "accepting" the new standard for the Editor performance, or undoing what was already introduced (which most likely other stuff is already dependent on, so this is a no-no)

oh well, i guess ill stick with 2020.1 as long as i can

at least its only Editor performance...

 

I ran into this problem after upgrading to Unity 2020.2.0f1 from 2020.1.17f1 (at least that's when I noticed it). It seemed to be the worst (generally speaking) when my A* grid was active in my scene (with pretty much everything else turned off other than the player character).

I ran the profiler and noticed that a lot of resources were being given to VSync stuff... Which I had never turned on. I then went and looked at my video output settings for the play mode in the editor, I confirmed VSync wasn't on... and found that the view was set for QHD, which I had also never set (I was using the 16:9 setting as I recall). I tried to change this back to 16:9... and then my FPS dropped to 1-2 FPS... I then went through each of the view settings, and the FPS stayed dropped at 1-2 FPS, even after returning to QHD.

Not sure if this is helpful... Thought I'd add my 2 cents.

 

Sorry to pile on to this, I just posted an own thread because I was unaware of this, even though I've been facing this problem for months.

https://forum.unity.com/threads/idl...-in-2020-2-versus-2020-1-and-earlier.1027675/

Can absolutely confirm I am getting only 5% to 10% of the performance I would expect starting 2020.2.

Play Mode, 11 ms CPU on an empty scene (with some DOTS systems in the background but they don't do much - but they seem to be perhaps tied to this issue)


Meanwhile, the profiler thinks I'm doing really well (or rather, proves the time is lost in Editor Loop):

 

You can switch to Editor instead of Play Mode profiling to see more details about where time is spent in the editor loop.

 

So trying out 2020.2.0f1, it seems my previously observed editorloop performance reduction is gone!

However, the ~15% Playerloop perf reduction is still there (culprit is in URP render camera stack). Attached are my profiler captures.

edit1 (editorloop) and play1 (playerloop) are using 2020.1.17f1 with URP 8.3.1
edit2 and play2 are using 2020.2.0f1 with URP 10.2.2

 

Timeline is becoming less and less useful. It's not really helpful to show the same time multiple times especially as the number of entries grow that reflect the same time. Even worse then you have specific categories like render thread. So jobs debugger time for instance ends up making the render thread time increase which also reflects in the stats window render thread time. 2-3 times removed from the actual source.

Somehow time that is shown more then once needs to be reflected as such, so it's clear hey this isn't necessarily rendering related at all.

 

I did give a specific. But I'm surprised the approach to this seems to be let's try to solve for every specific scenario. You can't solve this problem that way because scenarios are nearly endless. Pretty much anything can reflect in any other timeline (and then conflated with other stuff also) and how that becomes confusing to reason about is the bigger issue.

For instance in the screens below the root cause is the jobs debugger overhead from Unity.Physics. But it could be anything, my own gamelogic for example would also bleed over into the render thread timeline.

And the more timelines you add the more confusing it is. People are going to look at what seems most obvious. What is actually the most helpful is often obscured and that's really just inherent in how the timeline works. Like the actual physics time is in the timeline here but it's barely visible, certainly not what people are going to notice.

Plus the mouse overs break stuff down even more with the sources not apparent in many cases. Like the Gfx wait on the render thread shows 12ms but has a Total of 18 with 25 instances. The semaphore wait shows 128 instances.

But again specific scenarios are not really my point. There are endless scenarios here that make the timeline worthless without correlating with other things. That's actually been the case for a very long time and if you were not aware of it, you aren't testing your own product against enough variety of content. Like not testing against DOTS/HDRP would indicate to me you guys do very little testing against what your actual users are using. The impact of the jobs debugger and semaphore waits should be an obvious we need to test that sort of thing.





The stats window here is just an unfortunate casualty of the timeline. See how the render thread time here is high, that's all the jobs debugger impact from physics. But it's also not because of the way the timeline conflates things. The jobs debugger is only around 5ms of time, but it gets doubled by the time it reaches the stats window. (without jobs debugger render thread shows around 10ms).

 

I think part of the problem is trying to cram too much information into too few views.

You have multiple lines that often show the same block of time multiple times just with different labels. And you stack that vertically in the UI.

Add to that you also show the same wait time on multiple lines.


For example a simple at a glance view I would prefer something like two lines. One for the main thread one for jobs. So the main thread timeline clearly shows wait time and run time without duplication/overlaps, but sacrifices runtime details. Right under that you have the job line. And in the job line maybe break out the job entries by color to denote jobs being waited on. So those correlate exactly with the waits in the main thread timeline.

If you want to drill down into a specific block of time for details, that's properly a separate view. Which you could easily do with the space that you have if you just used it more effectively.

 

Ya I realize you only have so much data to work with for stuff like synchronization primitives. It's unfortunate especially when it comes to synchronization because the only hook you have now is what triggered the wait. That constantly trips people up especially if they don't understand how the synchronization stuff works.

But good to know better stuff is coming.

 

So @DrabanL I'm not sure if you can confirm my last findings on your end (with the latest Unity 2020.2). Editorloop perf reduction is gone. Playerloop has ~15% perf reduction in URP render cam. If so then this should be resolved as the overhead in URP 10 is probably not a bug.

 

Unresolved, even with 2020.2.1f1. Editor is performing at 25% of what is expected

 

Can we just return the old FPS counter somehow?

Maybe show two FPS counters on stats screen?

 

To be honest, I would get rid of the FPS value altogether. It's a source of confusion for people who don't understand its non-linear nature. How many people complain here their FPS dropped from 4000 to 3000 and don't understand it's not a problem.

I would prefer if the stats overlay and profiler display milliseconds only. I believe it helps people to understand performance better. FPS is a value for the average gamer, not something a developer should use.

http://www.mvps.org/DirectX/articles/fps_versus_frame_time.htm

 

Pretty nice little article. I always had this idea, but never could put them in words so succinctly.

 

of course its a problem. the performance is worse - this is a fact.
if this is the new standard for "editor" workflow, then fine. but it doesnt mean that it does not exist.

Generally its based on the Stats view. However even if i measure with external tool (Fraps), 2021 performs worse than 2020.

Not to mention that i actually "feel" the performance impact, because my project (not an empty scene) runs on ~75 fps with 2020.1 vs 55 fps on 2021.1 (which is the reason i started this thread in the first place)

I do have multiple monitors, 60hz both. plugging off either of them does not make any difference.

(In yellow color is the fraps FPS counter)

 

Okay I can reproduce @DrabanL 's numbers using my own FPS counter (I also verified using FRAPS; they are pretty much the same). On my end and all using URP:

Code (CSharp):

1. 2020.1.17f1:
2.     Empty Scene: ~460 fps
3.     Sample URP Scene: ~320 fps
4.  
5. 2020.2.0f1:
6.     Empty Scene: ~400 fps
7.     Sample URP Scene: ~280 fps
8.  
9. 2021.1.0b1:
10.     Empty Scene: ~370 fps
11.     Sample URP Scene: ~250 fps

So this should be URP-specific. And the degradation is pretty bad. I always noticed the 10% to 15% playerloop pref drop in 2020.2. But 2021 is currently even worse.