Search Unity

Can the EditorLoop portion of the profiler be silenced?

Discussion in 'Scripting' started by cpuRunningHot, Sep 10, 2020.

  1. cpuRunningHot

    cpuRunningHot

    Joined:
    May 5, 2018
    Posts:
    94
    upload_2020-9-10_11-19-20.png

    I'm optimizing code, and using the profiler to seek out the peak, and then drill in to find out where the bottlenecks are. I noticed that several peaks are due to the EditorLoop, which should have no effect on the built game performance. So, can I disable profiling for the EditorLoop so it's easier to identify spikes that will actually affect game performance?
     
    cpuRunningHot, Sep 10, 2020
    #1

  2. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    38,692
    I think you have to make a build and profile the build. Profiling in the editor can be highly misleading in many other ways, and is definitely not recommended best practices, except perhaps for getting a ballpark feel on where things are chug-a-lugging.
     
    Kurt-Dekker, Sep 10, 2020
    #2
    cpuRunningHot and Ryiah like this.

  3. cpuRunningHot

    cpuRunningHot

    Joined:
    May 5, 2018
    Posts:
    94
    That's unfortunate. It's not the end of the world, but I just have to look at more peaks than normal. It's sort of pointless to have it there at all if it provides no insight and doesn't affect the final build.
     
    cpuRunningHot, Sep 10, 2020
    #3

  4. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    Profiling the editor isn't all that useful because your game will perform differently in the editor than in a build. Some things which are handled asynchronous in a build are blocking in the editor, none of the code optimizations which go into a build are done in the editor, etc. I don't use editor profiling for anything beyond looking for really big obvious screw ups.
     
    Joe-Censored, Sep 10, 2020
    #4
    cpuRunningHot likes this.

  5. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,451
    You can reorder the order of the categories and move "Others" to the top of the list. This will change the way the stacked graph will stack up the values which makes it easier to find spikes in the other categories. While EditorLoop isn't the only sample that contributes towards Others, it usually is the biggest one (unless you are spamming debug logs I guess). You can also click on the colored box left of "Others" to hide it entirely but then again, you might not find those spike frames caused by debug logs that way, so I'd go with reordering first and see if that helps.

    What the others mentioned in here still holds up though: Profile a build on your target device first to find areas that need improvements. Note these down and get as much detail on what needs investigating there while profiling on a device. Use Playmode profiling as a means to iterate on these issues faster or whenever you need to get more details from within the editor (but keep looking back at those notes you made). Once you think an issue is solved, make a build again to profile that and confirm it there.

    Also, if you are on 2020.1 or newer, consider using Windows/Analysis/Profiler (Standalone Process) to profile your playmode so that the Profiler Window itself isn't getting profiled in that EditorLoop sample. On 2019.4 you can also close the Profiler Window and start and stop recording via the F90 shortcut. Also, the less other Windows are open, the cleaner the Playmode Profiling data becomes.
     
    MartinTilo, Sep 11, 2020
    #5
    Joe-Censored likes this.

  6. cpuRunningHot

    cpuRunningHot

    Joined:
    May 5, 2018
    Posts:
    94
    Thanks MartinTilo! Lots of good info in here. Specifically, clicking on "others" does exactly what I was looking for Seems so obvious, I feel silly for not thinking of clicking on that :D

    upload_2020-9-11_14-2-59.png

    upload_2020-9-11_14-2-42.png

    Also, thanks for the tip about spamming the debug log may contribute to those spikes. I'll be sure to not keep "Others" off all of the time so I don't let those slip by. But when I'm specifically looking for spikes in my custom code, I'll turn it off.

    I'll be updating to 2020.1 at a convenient time, so will definitely use the Standalone Process for the profiler when I do.

    As for the Editor vs. Built profiling, I'm aware of the differences and how the info in the editor profiling is not entirely accurate. But for my purposes, I'm looking for big picture bottlenecks since I'm doing a lot of concurrent and multi-threaded programming and looking to minimize anything that is on the main thread affecting the frame rate.

    Thx again!
     

    Attached Files:

    cpuRunningHot, Sep 11, 2020
    #6
    MartinTilo and Joe-Censored like this.