Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice

Performance issue with playing in editor

Discussion in '2020.2 Beta' started by ryanzec, Sep 20, 2020.

  1. ryanzec

    ryanzec

    Joined:
    Jun 10, 2008
    Posts:
    696
    So I created a brand new URP project, and then create a new forward renderer / 2d renderer to use and then a new scene with just the default camera.

    In that latest 2020.1 I get this performance:
    2020-old-performance.png
    I then took that same exact project, upgraded it to 2020.2 beta and I get this:
    2020-performance-issue.png
    The weird thing in that according to the profiler graph, the performance of the beta seem in line with the current stable however the stat widget of the game window in the editor shows the beta at 3.4ms (was generally hovering around 3.0ms - 3.5ms milliseconds) and the stable version at 0.8ms (was generally hover around 0.8ms - 1ms).

    Is there a reason that the stats window is different from the profiler in the latest beta? One thing I noticed is that if you add the PlayerLoop + the EditorLoop time, that is more closely match to what I am seeing in the stat of the game window, is this something new?
     
    ryanzec, Sep 20, 2020
    #1

  2. ryanzec

    ryanzec

    Joined:
    Jun 10, 2008
    Posts:
    696
    Well I at least figured out what the profiler was not matching the stats window, I apparently disabled the Other part of the profile and that is where all the extra time was (which is part of the EditorLoop).

    Is there a way to have the stats window not include the EditorLoop when calculating FPS since that should get me closer to was the FPS of the game should be when playing standalone (since it won't need to run the editor)?
     
    ryanzec, Sep 20, 2020
    #2

  3. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,136
    Hi @ryanzec ,

    The performance regression you're experiencing is a known issue and currently being investigated. Have a look at this thread:

    https://forum.unity.com/threads/2020-2-0b1-performance-reduction.965363/

    No, there isn't. Generally speaking, the only way to eliminate the editor impact from analysis is by profiling your builds directly rather than in the editor. The next best thing is to use the new out of process profiler, that will at least remove the profiler itself from the equation.
     
    LeonhardP, Sep 21, 2020
    #3

  4. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,456
    FYI: The game view stats is already kinda doing that, which is not helping the confusion around this as this thread just proved, which is why this is in the process of getting fixed as part of this fix.

    As Leonhard mentioned, making a guesstimate here that would be meaningful would be pretty tricky for several reasons:

    1.
    Even if the target platform is a Standalone build on the same device, performance in the Editor will be different from that in a player for various other reasons than just "Editor Loop", e.g. Script debugging might be on, Logs from the Editor (also partially counting towards "Other") and processing of logs for the Console window. Different resolutions, multi-screen setups, editor tools and extensions taking up resources ...

    2.
    The Render thread work kicked of on the main thread during Player Loop can continue to get processed while the main thread enters the Editor Loop. This in turn could mean that you have e.g. 1ms Player Loop, 10ms Editor Loop, 5ms Render thread work from the Player. Now if we only took main thread timings to calculate the FPS and guesstimate out the Editor Loop, that'd be 1s / 0.001s = 1000 FPS. If we took Renderthread timings instead it be 1s / 0.005s = 200 FPS. But the Render work might kick of mid frame so it should maybe be 1s/ (0.005 + 0.0005)s = 181 FPS. But then again, without the Main Thread spending time in the Editor Loop, the frame would have had to wait for the previous frame to finish rendering and getting processed by the GPU (for which we don't even have the metrics in this display or in general on all graphics APIs yet) so that calculation could still be horribly off.

    3.
    You are likely not running Playmode at the same Resolution as the Standalone build?

    So, really, the best we can do is bring down the Editor Loop overhead, some of which might be coming from code in your own project (to find out if that is the case, use the Profiler, ideally Windows/Analysis/Profiler (Standalone Process), targeting the Editor instead of Playmode). Then, if you are running with only the GameView open and maximized, you might be getting closer to the performance of a build, but still, all of the above points remain, they are just toned down a bit.
     
    MartinTilo, Oct 2, 2020
    #4
    Hyp-X likes this.