Search Unity

Editor is taking 20 seconds to enter playmode in an empty scene

Discussion in 'Editor & General Support' started by lynxelia, Feb 5, 2018.

  1. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    414
    Hi @optimise!
    Looking at the bug status I don't think so - it is still assigned to a team and is in work.
     
  2. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    414
    Hi @Baste ,
    Thanks for trying 2018.3!

    Did you have Timeline View open? It should be generally ~10MB per frame in deepprofiling mode and ~4GB for enterplaymode frame with 20MB samples.

    This definitely sounds like a bug - we've been testing profiler with very large projects on enter playmode (20M samples) and didn't see that. Would it be possible to file a bug - this should be fast to fix with a repro project.
     
  3. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,495
    Sure, I could do that. Could you PM me a cloud storage link? Rather large project.

    I think I had timeline view open when I entered play mode, and then switched over to hierarchy mode to see what was going on.
     
    alexeyzakharov likes this.
  4. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    414
    I would recommend having hierarchy view open when using deepprofiler (for now)
     
  5. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    699
    Is there any progress on improving on enter-to-play mode? As project size gets larger, it is getting really ridiculous and it's killing productivity. It's really a cancer causing.

    This is by far the worst problem working with Unity, period! Yet Unity has no solution but blaiming Asset developers(Joachim did say that). I'm hunting Asset develpers down one by one but it's too much work and many don't listen.
    If you are going to keep on blaimng the Asset developers, please put some strick restriction for the AssemblyReload at the store submission.

    And I know you said something about resetting scene instead of reloading. I'll take anything at this moment if it can help. Any early preview fix will be appreciated.
     
  6. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,816
    Here are a few of my answers regarding EnterPlayMode issues. I would fire up the profiler and check what's slow. It's explained in the first link.

    How to measure what's slow in EnterPlayMode. What's missing in the video is that you should also try to enable "Deep Profiling" to get more detailed information.
    https://forum.unity.com/threads/really-slow-to-enter-play-mode.468963/#post-3056065

    The number of GameObject's in a scene cause the editor to slow down a lot. See "EnterPlaymode" on this page. If you use asset store plugins that to spawn tens of thousands of game objects in the scene, this does not scale with Unity. It's a known limitation for years.
    https://forum.unity.com/threads/5-6...e-of-open-savescene-and-enterplaymode.447500/

    (Runtime)InitializeOnLoad can cause EnterPlayMode to slow-down
    https://forum.unity.com/threads/enterplaymode-slowness.526819/#post-3636661

    Loading scenes in parallel can cause EnterPlayMode to slow-down
    https://forum.unity.com/threads/how-to-reduce-enter-play-mode-time.484279/#post-3155183

    How EnterPlayMode is affected by adding more assets
    https://forum.unity.com/threads/how-to-reduce-enter-play-mode-time.484279/#post-3155777
     
    Last edited: Apr 14, 2019
  7. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    699
    Thanks but I did everything I could to minimize the load time. I have more than 60GB Assets and Unity simply just cannot scale up.

    It's pure BS how it is left like this for all these years, yet they talk about Performance by Default.

    The problem is that it shouldn't reinitialize everything every freaking time it tries enters the play mode.

    UE always enters the play mode instantly no matter how big your project is and it's been working like that more than 10 years.

    Why Unity can't fix the sh** that makes it the most unproductive? And it's eating everyone's life away everyday.

    I'm sick and tired of dealing with the mess they created.
     
  8. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,816
    Do you know if the problem in your case is the number of GameObject's in a scene or the number of assets in the project?
     
  9. f0ff886f

    f0ff886f

    Joined:
    Nov 1, 2015
    Posts:
    201
    I've been recently trying to run the deep profiler to understand why things are taking so long. It's about 14 seconds for me, 30GB of assets, scenes that have about 100-200 GameObjects (not created by assets).

    I've found two culprits so far (well I don't know if the asset itself is to blame), but people can follow the progress here for:

    Rewired: https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-104#post-4426885
    Odin Inspector: https://forum.unity.com/threads/rel...ate-workflow-tool.476949/page-16#post-4426891

    I'll post a summary back here when both of those threads conclude.

    I've been struggling with this a lot. I've promised to never use Unity again when I finish this project, its been 4 years of time at night spending maybe 30-35 seconds on average to test a simple code change. I don't know how much time I've spent over those years waiting for Unity to just recompile+enter play mode. I appreciate the work that Unity has done to make it possible for me to make a hobby dream come true, I just wish they used their own engine to try and release an actual big-ish game. Not a cinematic, not some ECS toy project, not a mobile Flappy Bird clone, but an actual game (use Xbox One S as a target).

    Unity could benefit from that experience of using its own tools, then we all would :) Other engines got massive steps forward when their developers were forced to use them for more than toys.
     
    Last edited: Apr 14, 2019
  10. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    110
    Any update on this? I also started going down the rabbit hole which is `reload assemblies`. It takes 8s while compiling takes only 0.88s.
    How can I avoid this? Every minuscule change takes 10s to be applied, that's _really_ bad!
     
  11. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    414
    The experimental EnterPlaymode without domain reload will be available in 2019.3 alpha. That should save some time in case scripts didn't change, but would cost scripts changes to support it.

    Please make a profiler capture (with Profile Editor) and check if you can see any calls related to your or package code.
     
    SugoiDev likes this.
  12. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,495
    That's going to have to be an optional toggle. I'm really in favor of not having domain reloads when entering play mode, but since that will keep values of static fields around, it'll break backwards compatibility hard.

    It's one of those "great idea for new projects, should not be used in large, old projects" kinds of deals.
     
    alexeyzakharov likes this.
  13. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    414
    Yes, definitely! It is opt-in Editor ProjectSetting. We can't make it default for now as it changes the behavior. As mentioned before there are 2 major behavior changes in scripts lifecycle - no statics reset and keeping existing object data (fields marked with [NonSerialized] remain).

    I would say it depends on how much time team is interested to commit making changes in the existing project :)
    We've tested it on very large project and it required quite a lot changes (~700 lines of code), but the effect was quite significant for artists - 20s -> 2.5s.
    We would like to collect the feedback during the alpha/beta phase and see in which form this mode should exist (e.g. extra play button or default mode) and should it exist at all. So far our expectations are that it might save time in 2/3 of cases when entering playmode (based on Editor stats).
     
    SugoiDev and Baste like this.
  14. neshius108

    neshius108

    Joined:
    Nov 19, 2015
    Posts:
    110
    For future readers, after lots of tests, here is what I did to manage to go from 9-10s to 6-7s in the compile/reload times:

    1. Moved imported assets and general tools into the "Standard Assets" folder (name has to be that)
    2. Removed as many files as possible (I went through and deleted all the Docs/Example/Demo folders from the assets I was using), their size is not necessarily important
    3. Removed default packages which I didn't need: Ads, IAP, Analytics, Multiplayer, XR Legacy, Memory Profiler (you can always bring them back whenever you actually need them)

    Notes: if, for some crazy reason, someone doesn't use the attach debugger feature in VS-Unity, disabling the "Editor Attaching" from the preferences, actually makes the reloading quicker (about 0.3-0.5s for me).

    Other crazy stuff I found:

    Unity seems to spam registry calls for certain player prefs, if they are not found, it will still try and try and try. Using process monitor, you can actually find the key and create an empty one in the registry. Little bit of a hack but worked and it stopped wasting time there.

    As a side note: it turns out Unity loads the verdana(b) fonts every single compilation, it only takes 0.003s but yeah it adds up :p

    And now, I can finally go back to develop in peace :rolleyes:

    EDIT: Posted a little tutorial/post about the adventure: https://gamejolt.com/games/talesofk...attempting-to-decrease-compile-times-she9y7qf
     
    Last edited: May 8, 2019
    christh, gresolio, Afroman and 3 others like this.
  15. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    699
    Hi, @alexeyzakharov
    I just tested the "Instant Enter to Play Mode" preview in 2019.3. It is really amazing! That's what we've been waiting for all these years and finally, we have some hope. Many kudos!

    After seeing the possibility, I cannot simply wait much longer. It's doable and but assets need to make some adjustments to take advantage of it.
    Since it's an optional feature, why can't we bring it to 2019.2? I'm sure it won't harm the existing project if you don't turn it on.
    But if we can bring it to 2019.2, I can start asking asset developers to fix their assets as soon as 2019.2 releases.
    No one will try to adjust their asset until 2019.3 is released and it might take half a year before anyone does anything about it.

    Could you please do me a big favor? Can you please bring it to 2019.2. As I said, since it's an optional preview feature, no one will get harmed by it.

    Thanks.
     
    alexeyzakharov likes this.
  16. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,816
    Is there a scripting API exposed, which can be used to force a domain reload?
     
    alexeyzakharov likes this.
  17. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    414
    Yes, we are planning to expose the relevant APIs in 2019.3. At the moment there is undocumented, but public
    UnityEditorInternal.InternalEditorUtility.RequestScriptReload
    API which forces domain reload next editor tick (but after script compilation if Editor is compiling). We'll expose similar method in a public api space properly.

    @Peter77 What is the use case you are thinking about?
     
  18. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,816
    Thanks for the quick reply!

    I thought if we're going to use this feature, it's probably causing some issues with statics for example. In order to quickly find whether this might be related to the missing domain reload, I would expose a menu item "Reload Assemblies".
     
    alexeyzakharov likes this.
  19. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    699
    @alexeyzakharov,
    You skipped replying on my comment. I really like to ask you once more.
    To me, 2019.2 is probably the least exciting release feature-wise in the last a couple of years. This feature can easily make 2019.2 the most exciting release easily. Can you please reconsider to bring it to 2019.2 as optional preview feature? If you can't, what's holding it?
    There has been many delays on many features in the past, and can we have something earlier than scheduled at least once?

    Thanks.
     
    alexeyzakharov likes this.
  20. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    414
    Thanks for trying out the feature! My hope is that is adoption is good, we could ideally make this default and only do domain reload when scripts change (or upon a special request). Then it would also open a path for the partial code patching or other "hot" reload approaches that could speed up the script iteration workflow.

    Sorry, I didn't skip or ignored - it is just that I can't simply positively answer your question or promise that I do a backport yet :(. I've notified our Release Management about the request. Even the feature is optional it adds some risks and is not allowed to be backported to the 2019.2 which is currently in the stabilization phase.
     
    Last edited: Jun 11, 2019
    SugoiDev and Peter77 like this.
  21. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    699
    Sigh.. sounds like it will push back the adoption at least 4 or 5 months then.
    We should've tried to target 2019.2 when we first discussed.

    If it's too late, please try to make sure the adoption as easy as possible for Asset developers.
    Most of the major assets have to support Instant Play Mode, otherwise, it is no use at all.
    This is what I'm worrying about.

    Thanks.
     
    Last edited: Jun 11, 2019
    alexeyzakharov likes this.
  22. SmartMediaNL

    SmartMediaNL

    Joined:
    Sep 29, 2016
    Posts:
    70
    I normally do not use Beta versions of Unity let alone Alpha versions but in this case i could not resist the temptation.
    The workflow time improvement is just amazing! It's a pity it took so long to get this addressed. It works so well i don't want to step back again (Aldo I might regret it later on ;-) ).
    For me at least this and the new prefab system are the best upgrades in years!
     
    chrisk likes this.
  23. Crossway

    Crossway

    Joined:
    May 24, 2016
    Posts:
    445
    alexeyzakharov
    I'm using Unity 2018.3.1f1 and can't update to 2019 anytime soon so is there any patch for Unity 2018.3.1 to fix this issue?
     
    alexeyzakharov likes this.
  24. alexeyzakharov

    alexeyzakharov

    Unity Technologies

    Joined:
    Jul 2, 2014
    Posts:
    414
    I don't think it is possible - we don't backport "features" to the released versions. Maybe try support channels - it should be possible to make a custom Unity build.
     
  25. shawnblais

    shawnblais

    Joined:
    Oct 11, 2012
    Posts:
    322
    It's great that you guys are adding ways to sidestep Domain Reload for artists, but obviously 20s reload times for scripters is also quite unbearable. As projects grow, the ability to prototype rapidly, falls right off a cliff.

    Is there any plans to actually fix the core issue here, which is extremely slow domain reload? Changing 1 line of code, forcing an entire reload of every object in memory doesn't seem like it should be the desired behavior. Especially not in an era where we have things like Flutter doing hot-reloads on-device in <100ms.

    I realize this is likely a massive issue, but this is probably the #1 issue with Unity right now, is it's total lack of ability to scale, and this right here, is at the heart of it. This needs to be #1 on the top of the RoadMap imo. Rolling out 1% initiatives like DOTS, without addressing core iteration time of the engine that effects 99% of us, seems a bit crazy.

    The addition of amdefs's seemed like a valiant effort, but the 1-2s overhead for each asmdef totally eclipsed the .3s of compile time you would save. Especially as it turns out, the bulk of the time is not compiling, it's this domain reload.

    We really need a solution here where we can still actually prototype game mechanics, in a code base with 5000+ scripts. I get that "Low reload time" doesn't look that sexy on the yearly marketing bullets, but it's everything for us in the trenches.

    Some how I'm sitting here in 2020, with a 16 thread Ryzen, changing 1 script file, and waiting 12 seconds for a reload. It's kinda sad :(
     
    Last edited: Jul 15, 2020
    learc83 and TofaPT like this.
  26. shawnblais

    shawnblais

    Joined:
    Oct 11, 2012
    Posts:
    322
    Please yes. I must imagine adoption is pretty good now, a yr later? I know 3 mths ago no one on our team knew about it, now it's on by default for all devs.

    If patching is possible it would be an absolute game-changer for Unity's ability to build larger titles. Hot-reload is cool but not all that integral, just getting the basic reload time down to <1s would be amazing for productivity.
     
    Last edited: Jul 15, 2020
    learc83 likes this.
  27. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,816
    I wish Unity would improve the domain reload after a recompile too.

    For the meantime, what I just recently found is that "Edit and Continue" FINALLY works with Unity (using VS 2019 and lastest VSTU).
    https://docs.microsoft.com/en-us/visualstudio/debugger/edit-and-continue?view=vs-2019

    It seems these highlighted settings are needed:

    upload_2020-7-15_7-41-6.png

    I use it like this:
    • Playing game in Unity
    • Find something that doesn't work, set Breakpoint in Visual Studio
    • Attach Visual Studio Debugger
    • Program execution halts at Breakpoint (you probably could also just "break all" with a button)
    • Change code
    • Press Continue
    • Continue playing in Unity without domain reload
    This is useful to iterate on a small piece of code quickly, as Visual Studio also allows you to set the Program Counter (Set Next Statement). It allows me ti just test a specific code block over and over again without having to rely on normal program execution flow.

    However, this "Edit and Continue" feature has its limits. It seems to work with simply code changes only for example.
     
    gresolio, shawnblais, learc83 and 5 others like this.
  28. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    351
    Great find, Peter!
    I'll be sure to test it with Rider as soon as I can!
     
    Peter77 likes this.
  29. learc83

    learc83

    Joined:
    Feb 28, 2018
    Posts:
    41
    I'm having a similar problem. 15-20 second compile times with debugger enabled, 8-10 seconds without. This is on a new machine with a 3900x and a small to medium sized project.

    I tried profiling to see if I could figure out what's taking so long. 50% of the time is taken by AttachToEntityClonerInjection.Initialize, and way down in the hierarchy below that TypeManager.InitializeAllComponentTypes()

    I tried saving my profile information to post, but it won't let me since the frame size is greater than 2GB.
     
  30. shawnblais

    shawnblais

    Joined:
    Oct 11, 2012
    Posts:
    322
    Woah, if this works, it could be a great workaround. Looks like it doesn't work in 2019.3. Is this a 2020.1 only feature for now?
     
unityunity