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

Bug Unity 2020.1.0b2 Editor loop taking 280 ms

Discussion in '2020.1 Beta' started by Zylkowski_a, Mar 26, 2020.

  1. Zylkowski_a

    Zylkowski_a

    Joined:
    Jul 27, 2019
    Posts:
    157
    I just updated my Unity to beta 2020.1.0b2. I don't have any code which affects editor and when I press play and open profiler all tabs in unity start blinking and profiler shows that editorloop takes ~280ms. Screenshot from profile. How should I fix this problem?
     
    Zylkowski_a, Mar 26, 2020
    #1

  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,452
    Can you check what that delayed call is? Also maybe switch to Hierarchy view if the performance of the ProfilerWindow currently prevents you from inspecting this further. A fix for it's performance is on its way.

    If that (or those) delayed calls are not from your code or some Assetstore extensions, please file a bug report.
     
    MartinTilo, Mar 28, 2020
    #2

  3. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    1,123
    We noticed this happens in b3 if the lighting settings window is open during play mode.
     
    Prodigga, Mar 29, 2020
    #3

  4. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,334
    Could you please stop opening the Timeline view by default? It's essentially useless for the vast majority of us that's not on DOTS. I have to switch over to Hierarchy every single time I open the profiler window.

    Or at least have the Profiler remember the last opened view.
     
    Baste, Mar 30, 2020
    #4
    phobos2077, goncalo-vasconcelos, Peter77 and 1 other person like this.

  5. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,452
    Could you please file a bug report for this?


    It's an EditorPref so it already restores to the last state it was in, unless this was bugged in some version?

    I think about everyone has stuff executing in the Render Thread and Hierarchy view has currently no way to show how the timings of the Main Thread and the Render Thread interact with each other to contribute towards the frame time. Judging by how often people get stuck on a WaitForSomething sample while looking at Hierarchy view, I just don't think it's the most useful view to show to people opening the Profiler for the first time. I'm very open to suggestions on how to solve both though. :)

    As I said, we're working hard on making it more performant and more useful, adding execution flow (also to highlight Main Thread <-> Render Thread interplay) etc. I'd also be very happy about any additional feedback on how to make it more useful to you @Baste
     
    MartinTilo, Mar 30, 2020
    #5

  6. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,334
    I'm on 2018.4. Did you perhaps introduce the EditorPref in a later version?

    Look, I've never really liked the timeline view. I know that it's crazy difficult to visualize parallel threads and which ones are doing what when, so it's probably not doing a bad job at that, but it's a bunch of boxes with tiny labels and vastly different zoom amounts. If I want to know "which of my MonoBehaviours is being slow", which is most of what I'm using the profiler for, the best way to solve that is to get an ordered list of frame times.

    People not understanding "WaitForX" is due to lack of knowledge. It's not going to be fixed by showing people a bunch of boxes they also won't understand. The Timeline view is massively more complex than the hierarchy! That's not fixable, because you're showing more complex stuff (mutli-thread vs. main-thread).

    As long as DOTS is not the default way to write code (so, idk, until 2025?), having a view who's main feature is solving the "how do we display profile results for multi-threaded code" as the default one is the wrong choice.

    If you want to reduce the amount of people making posts and getting confused about "My editor is slow because you do this WaitForPresent thing", just rename the damn "WaitForPresent" sample to "Waiting For Render Thread" or "Waiting for GPU" already. You should have done that years ago, and that'd fix almost all of the noob confusion out there.
     
    Baste, Mar 30, 2020
    #6
    phobos2077, Peter77 and goncalo-vasconcelos like this.

  7. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,452
    Whoops, looks like it. I've opened a bug for it, the fix is on its way.

    Also, thanks for the Feedback. We've been pondering to hide the internal (grey, e.g. Semaphore.WaitForSignal) samples by default. Also Gfx.WaitForPresent has been renamed to Gfx.WaitForPresentOnGfxThread in 2019.2 (still not ideal but with Native Gfx threads technically more correct than Render Thread). Renaming the samples is not ideal when considering the usecase of comparing profiler data across Unity versions (e.g. with Profile Analyzer) and would break Recorders on version update. It might be reasonable to display a clearer name for them in the Profiler Window UI in a default, "simplified" view, if it is made clear to users of the Recorder API that this is not the actual marker name... I'll bring this up in the team :)
     
    MartinTilo, Mar 30, 2020
    #7

  8. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,452
    FYI @Baste 2018.4.21f1 now remembers the last chosen view.
     
    MartinTilo, Apr 11, 2020
    #8
    Baste and Peter77 like this.