Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

Unity assembly definition files slower, not faster - how to compile faster?

Discussion in 'Editor & General Support' started by nicmarxp, Jan 4, 2018.

  1. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    982
    Slight necro, but this is not that crazy. Enabling debugging in the editor has a *very* heavy performance cost. Most of the time it does not matter, especially considering it's ridiculously useful, but the slowdown is not surprising.
     
  2. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    110
    @AlkisFortuneFish perhaps I wasn't too clear: the setting slows down even if you never ever use the "Attach Debugger" feature. It slows down the editor just to have the possibility of attaching the debugger.
     
  3. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    982
    Yes, that is precisely what I mean too. There was a post about this at some point in the past year or so, enabling "Editor Attaching" incurs a heavy performance cost, whether you are debugging or not.
     
  4. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    110
    Great but to me that's not really obvious, leaving a socket open for something to communicate with it shouldn't have any noticeable slowdown. Maybe that's just me :p
     
  5. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    982
    It's a bit worse than that, unfortunately! :p
    The code generator inserts a ton of extra checks to handle debugging, whether you are attached or not, so *all* managed code, as well as loading and reloading it, is slower. I cannot find the original post, but it is mentioned in a blog post by @Aras when he was benchmarking his raytracing code.
     
    Last edited: Aug 2, 2019
    karl_jones likes this.
  6. nicmarxp

    nicmarxp

    Joined:
    Dec 3, 2017
    Posts:
    406
    This is very interesting, but for me the time between pressing save in the IDE (rider in my case), the scripts compile and the editor reloads is more of a time sink than entering play mode.

    is this also related to domain and scene reload and will it be possible to disable that, or is it only on enter playmode?

    thanks for working hard on this, looking forward to test when 2019.3 comes out stable. :)
     
  7. hertz-rat

    hertz-rat

    Joined:
    Nov 3, 2019
    Posts:
    71
    OP is unhappy about 5-7 seconds to enter play mode, so I thought I would time my own editor in 2019.3 using HDRP and a relatively powerful gaming computer.

    Including letting the compilation happen and hitting play, from when I hit 'save' in my IDE to when I can interact with my scene, is 33 seconds. Sometimes its only 18-25 seconds if I didn't modify any c# files.

    If my project is 3k LOC with very few assets now, does that mean it will take 3 minutes 6 months from now? What do you do to avoid it if the assembly definitions don't speed it up?

    Profiler says its moslty split between 'ReloadAssembly' and 'LoadScenes' and 'UpdateScene'
     
    Last edited: Feb 12, 2020
  8. nicmarxp

    nicmarxp

    Joined:
    Dec 3, 2017
    Posts:
    406
    hertz-rat and karl_jones like this.
  9. hertz-rat

    hertz-rat

    Joined:
    Nov 3, 2019
    Posts:
    71
    I'm using a handful of static fields and events unfortunately so I've shyed away. Also, 99% of the time I press play its after a script change. I think this feature is just for when there were no script changes? I could be wrong about that
     
  10. nicmarxp

    nicmarxp

    Joined:
    Dec 3, 2017
    Posts:
    406
    I just tried it, and it's amazing. By using the shortcut CMD-P or CTRL-P it seems to go even faster. Not sure why, but I love it :) I guess, don't use static, but not sure how to replace them :)
     
  11. Tortuap

    Tortuap

    Joined:
    Dec 4, 2013
    Posts:
    137
    You can use static, just initialize them, like so :

    Code (CSharp):
    1. public class MyMonoBehavior : MonoBehavior
    2. {
    3.     static int myStaticCounter;
    4.     static Action myAction;
    5.  
    6. #if UNITY_EDITOR
    7.     [InitializeOnEnterPlayMode]
    8.     static void InitializeOnEnterPlayMode ()
    9.     {
    10.         myStaticCounter = 0;
    11.         myAction = null;
    12.     }
    13. #endif
    14. }
     
    SolidAlloy and florianhanke like this.
  12. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,988
    You stop using Unity.
     
  13. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    679
    You don't need to use Editor stuff,

    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)]
    wiill work too
     
  14. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    110
    This is an awful reply, brings absolutely nothing to the conversation.
     
  15. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,988
    Thanks for the information.
     
    neshius108 likes this.
  16. Tortuap

    Tortuap

    Joined:
    Dec 4, 2013
    Posts:
    137
    Nope, the code I'm giving is to re-initialize static variables when you enter play mode, while you have disabled domain reload under the Editor (to enter play mode faster).
     
  17. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    679
    Yeah but this callback fires later than the SubsystemRegistration one from what I recall, so SubsystemRegistration is still the best place for it, and is not an editor API.

    Edit: seems like it is not the case anymore (or never was), InitializeOnEnterPlayMode does trigger before SubsystemRegistration. (Unity 2021.3.6)
     
    Last edited: Aug 25, 2022