Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Join us on Dec 8, 2022, between 7 am & 7 pm EST, in the DOTS Dev Blitz Day 2022 - Q&A forum, Discord, and Unity3D Subreddit to learn more about DOTS directly from the Unity Developers.
    Dismiss Notice
  3. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Official Long waiting times in the Editor - Slow asset refresh when modifying any script

Discussion in 'Editor & General Support' started by LeonhardP, Oct 2, 2020.

Thread Status:
Not open for further replies.
  1. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,021
    Hi everybody,

    Since the release of the Asset Import Pipeline v2 in 2019.3, we have seen an increase of reports about long waiting times during domain (re)loads and asset refreshes. If you are experiencing unusually long wait times after making changes to your scripts, it is likely because of an issue in this area.

    We're starting this thread to inform you about possible sources for these issues in your projects and to share updates with you on what we're doing in order to improve the situation on our end.


    Primary Source of the Problem
    During domain reloads all ScriptableObjects which were instantiated at the time of the domain shutdown will get restored. If any of those objects have complex initialization it might negatively affect domain reload times. A strategy which can be used to mitigate this issue is to either initialize those asynchronously or delay some aspects of initialization at usage time rather than at creation time.

    If the above is the source of slowdown you should be able to see while profiling the Editor the following pattern RestoreManagedReferences taking a significant chunk of time spent.



    Degradation of domain reload times during the lifespan of a specific editor session might also happen. Those can be caused by the creation of ScriptableObjects in the static constructor of a class with the [InitializeOnLoad] attribute or a method with [InitializeOnLoadMethod] attribute. What is happening in this case is that on domain reload ScriptableObject instances get restored and [InitializeOnLoad] gets called again causing an extra instance to be created and initialized.

    In 2020.1 and up, one way to address this is to make the ScriptableObject a ScriptableSingleton. If you do not need this object to be a ScriptableObject, another alternative is to use a plain old C# object.

    As mentioned before be mindful of the initialization of those objects created on load as it will impact your domain reload times.

    For more information please have a look at our blog post about Tips for working more effectively with the Asset Database


    Known Issues and Progress Updates
    • 1282694 - Odin Inspector causes slow domain load times
      • Odin Inspector prior to version 3.0 is another popular asset that can trigger a degradation of domain reload times and slow domain load times. We've contacted the developers and reported an issue that we discovered. Besides the one we told them about, which can cause degradation, they're aware of other ones as well, mostly causing slow domain load times. Those are already fixed in their current 3.0 beta.

        If you're using Odin Inspector and are experiencing slow or degraded domain reload times, it might be worth a try to check out version 3.0 if possible.
    • 1176913 - High CPU Load when editor is trying to trim full GI Cache
      • If you are seeing entries in your Editor Log with the form:
        TrimDiskCacheJob: Current cache size XXXXmb
        LocalFileCache size was not reduced below threshold at path:
        This might slow down your domain reload. You can adjust the size of the cache in Preferences GI Cache and/or Clean the cache.
    • If you use Burst, upgrading to Burst 1.4.0-preview.5 should allow you to save some time. In the case of the project we tested it with, it saved around 0.2 seconds on every domain reload.
    • Using the DOTS package, there is a known issue where IL PostProcessing will add some time to Domain Reload as some logic is required to run in order to enable some of the features which DOTS uses. There is some work in progress with regard to the main offender, and the idea is that it should improve this situation greatly in the near future.

    If your increased domain reload times are not caused by one of the above issues or your own code, please consider submitting a bug report with a reproducible project attached to us so we can investigate.



     
    Last edited: Nov 6, 2020
    Bagazi, NotaNaN, wlwl2 and 10 others like this.
Thread Status:
Not open for further replies.