Search Unity

  1. Get the latest news, tutorials and offers directly to your inbox with our newsletters. Sign up now.
    Dismiss Notice

2020.2.0b1 Performance Reduction

Discussion in '2020.2 Beta' started by DrabanL, Sep 6, 2020.

  1. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    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.
     
    BozoBill and Xenerade like this.
  2. slime73

    slime73

    Joined:
    May 14, 2017
    Posts:
    70
    Does the Unity profiler show where the time is being spent?
     
  3. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    (URP default sample project)

    upload_2020-9-6_23-45-21.png

    upload_2020-9-6_23-46-15.png

    upload_2020-9-6_23-46-41.png
     
  4. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    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.
     
    Last edited: Sep 7, 2020
    DrabanL likes this.
  5. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    2,496
    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)
    1. Install the Profile Analyzer package.
    2. Set the Profiler to target the Editor. If the datasets turn out to lack depth later on, you can repeat steps 2 to 6 with Deep Profile enabled. Initially, Deep Profile should be turned off to avoid it's overhead from muddying the waters. Screenshot 2020-09-07 at 15.58.03.png
    3. Enter Playmode and start to record the profiling information.
    4. Let it run for a couple of seconds and then stop recording.
    5. Open the Profile Analyzer and import the sample you just took by clicking on Pull Data. Screenshot 2020-09-07 at 16.19.13.png
    6. Once the import process is finished, save the sample.

    Once both samples are saved
    1. Click on Compare in the Profile Analyzer window of any of the two project versions.
    Screenshot 2020-09-07 at 16.15.19.png
    2. Load both of the samples that you saved.
    3. Stretch the Profile Analyzer window so it fills out the screen.
    4. Right click on the graph and Select All.
    Screenshot 2020-09-07 at 16.38.20.png
    5. Then order the results below by Absolute Difference.
    Screenshot 2020-09-07 at 16.38.57.png

    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.
     
    Last edited: Sep 7, 2020
  6. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    upload_2020-9-7_12-46-47.png

    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
     
    Last edited: Sep 7, 2020
    richardkettlewell likes this.
  7. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
  8. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,324
    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.
     
  9. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,418
    Wouldn't the best thing just be to run the profiler as a standalone process? That should minimize the interference, right?
     
    MartinTilo likes this.
  10. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    upload_2020-9-8_19-44-46.png
     
  11. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    Any Unity folks (or anyone besides me and @DrabanL) able to reproduce this on their side now (on Windows)?
     
  12. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    Last edited: Sep 8, 2020
  13. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    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)
     
    Last edited: Sep 8, 2020
  14. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    @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
    upload_2020-9-9_18-2-19.png

    2020.1.4f1
    upload_2020-9-9_18-3-6.png


    250 fps vs 1000 fps
    insane!!

    -------------

    Same issue with 2020.2.0b2
     
    Last edited: Sep 10, 2020
    Ruslank100 and Creepgin like this.
  15. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    2,496
    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.
     
    MartinTilo likes this.
  16. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    Sure, done. Case 1277222

    Also, I tried on b2 that just came out, problem still persists.
     
  17. danp

    danp

    Joined:
    Jun 20, 2013
    Posts:
    20
    I'm seeing this also. Ms went from 3.2 in 2020.1 to 5.2 in 2020.2.
     
  18. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    2,496
    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 @Creepgin for submitting the bug report.
     
  19. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    409
    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.
     
    mahdi_jeddi and laurentlavigne like this.
  20. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,324
    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.
     
  21. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    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?
     
    alexeyzakharov likes this.
  22. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    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..
     
    Creepgin and alexeyzakharov like this.
  23. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    315
    If you don't have to debug scripts, you should always make sure that unity is running in release mode (if not already active).
     
    FakeByte likes this.
  24. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    147
    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
     
  25. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    409
    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!
     
    andreiagmu, Creepgin, DrabanL and 2 others like this.
  26. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    many versions later (including alpha)

    still the same... AND issue flagged as "Not Reproducible" in tracker o_O
     
    Ziplock9000 and Creepgin like this.
  27. danp

    danp

    Joined:
    Jun 20, 2013
    Posts:
    20
    I also recently tried the newest 2020.2 beta and performance was much worse than 2020.1.
     
  28. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    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.
     
    Last edited: Nov 24, 2020
  29. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    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...
     
  30. Vaulcul

    Vaulcul

    Joined:
    Apr 3, 2016
    Posts:
    40
    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.
     
  31. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    268
    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):
     
  32. slime73

    slime73

    Joined:
    May 14, 2017
    Posts:
    70
    You can switch to Editor instead of Play Mode profiling to see more details about where time is spent in the editor loop.
     
    MartinTilo likes this.
  33. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    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
     

    Attached Files:

    Last edited: Dec 24, 2020
  34. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,239
    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.
     
    Creepgin and velenrendlich like this.
  35. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,324
    As in the other thread, more specific examples and ideally screenshots would be good to see what can be clarified.
     
  36. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,239
    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.


    upload_2020-12-24_16-59-53.png


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

    upload_2020-12-24_17-9-18.png
     
    velenrendlich likes this.
  37. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,239
    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.
     
  38. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,324
    Alright, you did give specifics but since you were confusing some concepts here*, I just wanted some extra clarity on what you were talking bout without me jumping to conclusions based on a misunderstanding.
    (* I take full responsibility on that confusion, I guess the UI/UX and docs could be clearer on these.)

    So first off: Timeline view is just a way to display multithreaded work in chronological order and highlighting cross thread timing correlation issues and interdependencies. The different tracks in there each represent a distinct thread within the same timeline (the timeline being the chronological execution of your app across all these threads).

    The number the Stats view shows is the time spend from the beginning of processing render commands for the current frame up to the last command being end off to the GPU (including possible timings of it waiting on getting the next frame buffer from the GPU). It is therefore not explicitly counting these gray samples, which btw belong to the "Internal" Profiler Category because they offer a more detailed view into the internals of why there is nothing happening on that thread at this time,they just happen to fall in-between the measuring points. Btw, render thread time spend on Scene view or other Editor Window rendering work is excluded from the Stats View summary, as there is an internal editor context switch which pauses the measurements for the Stats View, also stopping the counters on Tris and Verts not to include these other views.

    In this specific example the gray samples on the Render thread just indicate that your main thread work is ordered in a way that is sub-optimal for utilizing the Render Thread to the full maximal effect.

    That's kinda fair. The Stats view is supposed to give a very high level overview without needing to explain every single value too much. maybe it could show active vs wait time on he Render thread but that then already needs more explanation and a differentiation between waiting on GPU/vSync and waiting on commands...
    The CPU Usage Chart also suffers from over simplification somewhat as it only sums up the categories for main thread timings. Btw gray samples on the main thread are treated as "transparent" for this categorization as the category/color of their parent samples is used instead.

    For 2020.1 we added the flow visualization which we extended in 2020.2 to show better what is waiting on what and how the execution flows. We have to balance profiling overhead and profile data readability, so we don't yet have flow visualization on every synchronization primitive (Semaphore, Mutex, SyncFence) as they in the ideal case should have near 0 cost as they don't actually have to wait if the work was scheduled optimally.

    We're therefore Implementing this in stages, ironing out the API, data emission and UI UX for this as we go, including optimizing the UI rendering to support this extra visualization. But ultimately this will lead to something akin to what you're asking for: Critical Path analytics and visualization. As it is now, to simplify the view to what you're asking for the profiler is lacking the data to do so and it wouldn't really be what's really happening.
     
  39. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,239
    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.
     
    MartinTilo likes this.
  40. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    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.
     
  41. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    Unresolved, even with 2020.2.1f1. Editor is performing at 25% of what is expected
     
  42. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,324
    Are those 25% based on the FPS in the Stats view or on Profiler Data? The profiler data I've seen so far doesn't support this crass a difference and for the stats view FPS count we already mentioned that it's based on bad math in 2020.1 and not to be trusted there?

    Do you have multi monitor setup? What's each monitors refresh rate (Hz) and what happens if you turn one or more off/ unplug them?
     
  43. unity_5-4zDtsn_EhETQ

    unity_5-4zDtsn_EhETQ

    Joined:
    Aug 19, 2018
    Posts:
    4
    Can we just return the old FPS counter somehow?

    Maybe show two FPS counters on stats screen?
     
  44. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,324
    The stats view has rather limited real estate and in playmode there are no tooltips to explain anything. We can try to cramp the old value in there but my question to you would be why?

    Why would you want an FPS count that is essentially a lie, and just based on the PlayerLoop? Why would you want and FPS count that would display an FPS value that would more than likely differ from any FPS display you'd implement yourself?

    If it is just based on the PlayerLoop time, it would only be somewhat accurate for titels that are main thread CPU bound. As soon as your titel is Render Thread, Jobs, GPU or vSync bound the count will be way off. You'd assume your game is doing fine, until you make a build that appears to have "worse" performance.

    The only reason I can see right now would be comparability across Unity versions and to end the kind of confusion in threads like this one.

    There also remains the issue of how to label this second value succinctly in the stats view to cause less, rather than more confusion over two FPS values, and "which one should I trust?"
     
  45. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,324
    Btw, you can set up a ProfilerRecorder to record the time for "PlayerLoop" and use that in your own FPS display. It's going to work in a build too and then be actually accurate. (Well, sorta as it'd miss the Profiler end-of-frame overhead where stats are flushed but that is rather minimal and you could add a ProfilerRecorder on that value too.)
     
  46. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,605
    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
     
  47. mahdi_jeddi

    mahdi_jeddi

    Joined:
    Jul 18, 2016
    Posts:
    147
    Peter77 likes this.
  48. DrabanL

    DrabanL

    Joined:
    Nov 13, 2014
    Posts:
    31
    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)

    upload_2020-12-28_19-15-30.png
    upload_2020-12-28_19-16-10.png

    upload_2020-12-28_19-17-56.png

    upload_2020-12-28_19-18-30.png
     
  49. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    411
    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.
     
    Last edited: Dec 29, 2020
    DrabanL likes this.
  50. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,324
    Hmm good point. Hadn't thought about that aspect of it yet. I mean, they both ARE showing the ms value and I think it might still be valuable to include the fps value but probably less prominently?

    More out of curiosity I've gone through the numbers in hose last two posts and converted them to ms and percentages of regression (I.e how much more time it took in newer versions based on the old total in ms)

    @Creepgin's values
    2020.1.17f1
    460 fps = ~2.174 ms
    320 fps = 3.125 ms

    2020.2.0f1
    400 fps = 2.5 ms
    280 fps = ~3.571 ms
    20.1 -> 20.2 regressed by 0.326 ms (15%)/ 0.447 ms (14.3%)

    2021.1.0b1
    370 fps = ~2.703 ms
    250 fps = 4 ms
    20.1 -> 21.1 regressed by 0.529 ms (24.3%)/ 0.875 ms (28%)
    20.2 -> 21.1 regressed by 0.203 ms (8.1%)/ 0.429 ms (12.0%)

    ---
    @DrabanL 's numbers:
    2020.1.17f1
    406 fps = ~2.463 ms
    262 fps = ~3.817 ms

    2021.1.0b1
    296 fps = ~3.378 ms
    183 fps = ~5.464 ms
    20.1 -> 21.1 regressed by 0.915 ms (37.1%)/ 1.647 ms (43.1%)

    All in all, not pretty numbers and we should figure out where those ms got lost to in the Editor. Not sure why our QA was not able to reproduce this though... is there any hint in Profile Analyzer? I'm on vacation and currently too far away from my PC to try to reproduce and analyze this...
     
    Last edited: Dec 30, 2020
    DrabanL, Creepgin and Peter77 like this.
unityunity