Search Unity

Reloading Script Assemblies takes a long time, and keeps getting slower

Discussion in 'Scripting' started by ge01f, Jan 22, 2022.

  1. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    On 2020.2.21f on Windows, and Reloading Script Assemblies happens every time I compile, and is now taking 40 seconds each time. With script compilation and reloading script assemblies and updating the editor, it now takes about 60 seconds every time I change a piece of code.

    I recreated this project from my main project just to get this time down, and with BOTH compiling and reloading script assemblies it was at 100 seconds in the large project. The large project was big, at 150GB, and had many different code assets. So ok.

    But this new project is leaned down to 9GB of assets, and a minimum number of code assets, and was only taking 10-15 seconds each recompile 1 week ago, and now it is almost as long as the huge project.

    Why does Unity not cache the Script Assemblies so it doesnt need to reload them? They havent changed, they didnt need recompiling. Is there some way I can fix this?

    It is drastically reducing the number of changes I can make in an hour and limiting my productivity and I dont think I can make the project any smaller and actually get the game programming done.

    I have everything that isnt my personal active game code in Assemblies, so they shouldnt need recompiling, but they still take forever to reload.

    About 5 seconds to compile scripts and about 43 seconds "Reloading Script Assemblies".

    final1.PNG
     
    Last edited: Jan 22, 2022
  2. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,618
    Hi,

    have you checked in the Profiler (via Editor Deep Profiling) what specifically in "Reloading Script Assemblies" is taking that long?

    Unity also calls [InitializeOnLoad] methods during this step and perhaps there is a plugin/package/etc that is doing an expensive operation. It could also be an AssetPostprocessor that triggers when a script imports. All of this should be visible in the Profiler.
     
    AldeRoberge, Whatever560 and ge01f like this.
  3. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    I didnt know it ran those during that phase. I will look into that Editor Deep Profiling for that. Thanks.

    Actually, I had Wwise shut down, and it looks like it did a full TCP timeout delay during the [InitializeOnLoad] section, so once I started that its back to 5 seconds for Reload Script Assemblies.

    Thanks. I'll see if there are any other offenders, but already back to 12 seconds after recompiling scripts, which is totally acceptable.
     
    jamestrue, Atopia and Peter77 like this.
  4. eightyonecats

    eightyonecats

    Joined:
    Mar 16, 2022
    Posts:
    1
    I'm also having this problem. I get "Reloading Script Assemblies" any time I start or stop my project.
     
  5. Atopia

    Atopia

    Joined:
    Apr 21, 2022
    Posts:
    1
    Same problem here !
    40s+
     
  6. gnovos

    gnovos

    Joined:
    Apr 29, 2020
    Posts:
    33
    Same problem here! I upgraded to 2021.3.2f1 and it went from taking a few seconds to get past "reloading ScriptAssemblies" to now around *15 minutes!* I tried both upgrading and downgrading, but the problem persists in every version now. I'm not sure what to try next or how to get it back to the state it was just a day ago other than eraing all the project files other than assets and trying to rebuild from scratch. :(
     
  7. myazuid

    myazuid

    Joined:
    Jan 29, 2019
    Posts:
    26
    Same issue here. Sometimes it seems making a small amendment to a script - adding a comment - whilst it is doing its recompiling knocks it out of it and it finishes quickly. But not always.

    I also have Visual Studio saying "Background analysis of asset and meta files has been disabled, because this project seems to large."

    Not sure if that's related. It isn't a big project at all. About 40 scripts in there, but the size of the project is not big.
     
    entropicjoey1 and thomasc8 like this.
  8. StellarVeil

    StellarVeil

    Joined:
    Aug 31, 2018
    Posts:
    73
    Did the profiler thing, didn't help cuz I have no access nor know most of the top consuming things shown there during the reload phase.
    I tried removing unused plugins and packages, big & small and still 0 difference in reload time which takes about 10 secs for an avg iteration time of 19 to 34s after each even minor code change added to the 15s for enter play mode and ~6s for exiting -_-

    It is an absolute pain to work with and yesterday I upgraded my 2020.3 LTS editor from 15f1 to 33f1 and was looking forward to this upgrade for a long time hoping they solved that issue and improved workflow speed but to my biggest disappointment they did not and postponed such important issue..
    I heard this issue wasn't present in 2019 and now I'm thinking about whether I can and should downgrade at the expense of losing a feature like contextual prefab editing pff..

    Edit: I tried downgrading to 2019 and there was no diff in asm scripts reload time.
     
    Last edited: Jun 18, 2022
    StatelySnail likes this.
  9. StellarVeil

    StellarVeil

    Joined:
    Aug 31, 2018
    Posts:
    73
    Can't they just give us a toggle that disables certain parts of the scripts assemblies reload process like they did for the domain reload ? Even if it would mean we have to make slight adjustments ourselves.
    The compile phase alone takes between 1.5f to 4.9s so there'd be a huge diff between an iteration time of < 5s and one taking 19 to 34 secs.
     
    ge01f and akuno like this.
  10. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    I would love to be able to control this, and suffer any foot shots I make on myself. I am constantly battling getting stalled for 30-60s because of reloading these script assemblies. It is an absolute productivity killer.
     
  11. denikotin

    denikotin

    Joined:
    Jan 28, 2022
    Posts:
    1
    Hey guys, I have got the same problem. When i just create a new script it takes about 2 second for "reloading ScriptAssemblies". Have somebody solve the problem ?
     
    drewjosh, vanyfilatov and sonbkap like this.
  12. Morseliot

    Morseliot

    Joined:
    Jan 10, 2015
    Posts:
    71
    Same here, after upgrading to 2020.3.35 from 2019 it take about 60s to reload assembly each remark in any script. PIA.

    Update: As I almost never shut down PC (using Sleep mode). Seems like Unity collects some "dump". So restarting Unity helps.
     
    Last edited: Jul 7, 2022
    Kokowolo likes this.
  13. ch_p

    ch_p

    Joined:
    May 30, 2017
    Posts:
    3
    Same problem there, restarting unity does not help. The time it takes is absolutely random. The problem pisses off seriously.
     
    Last edited: Jul 8, 2022
  14. IvanM71

    IvanM71

    Joined:
    Oct 28, 2019
    Posts:
    7
    Unity, do something with that please! 2021.3.5f1
     
  15. felipe-shida-playkids

    felipe-shida-playkids

    Joined:
    Sep 16, 2020
    Posts:
    13
    Same here, sometimes it does not require any script change and the "reload script assemblies" popup show up and freezes Unity for 20~30 seconds, really annoying and inexplicable.
     
  16. SamuelAsherRivello

    SamuelAsherRivello

    Joined:
    Jan 16, 2011
    Posts:
    42
    I'm in a relatively small project and experience 30-90 second delays to recompile (e.g. adding one empty line in a class definition). I would expect compilation to be < 5 seconds.

    • 2021.3.61 - 30-90 second delays
    • 2022.1.10.f1 - 30-90 second delays

    Anyone have a bug report link on this? I'll vote it up!
     
  17. DavidJares

    DavidJares

    Joined:
    Dec 18, 2016
    Posts:
    50
    Why tf!! is no one of Unity ever responding to these issues. Paying customers , broken productivity, giving a s* about us ? This whole trouble with assembly reloading etc exists quite a few years now. Thanks unity once more for nothing. Dont listen to what your customers and user say. Rather go ahead and work on some incoherent tech-playground-stuff that will be in alpha for years and deprecated anyways, but at least you have something to hype about. Dont even think about letting me copy and paste components with ctl+c and ctrl+v. f* off unity
     
    drewjosh, Marc-Saubion, Nido and 9 others like this.
  18. kayroice

    kayroice

    Joined:
    Feb 7, 2017
    Posts:
    49
    drewjosh likes this.
  19. DavidJares

    DavidJares

    Joined:
    Dec 18, 2016
    Posts:
    50
    Yeah I know. I read that thread. tldr is they mainly give a s* in practice. They are working on so much things. But Unity-Engine is a tool being used and payed for to PRODUCE things ( eg create and deliver games ). If they have such a blackhole regarding productivity-time and not focus an essential part of their workforce to work out a fix for this first, then they essentially show their middle fingers to us. I dont use pro but I have spent thousands on the asset store over the years - way more money than for any other software I ever used. As soon as a project gets more mature productivity goes down because of that. So yeah, f* that. The Unity-devs you mention don't seem to promote the urgencey of this problem. They keep living in their bubble.
     
    drewjosh, iNSiPiD1 and bobby55 like this.
  20. StellarVeil

    StellarVeil

    Joined:
    Aug 31, 2018
    Posts:
    73
    Nah it seems to me our voices land on deaf ears atm. They claim an improvement of 8-22% in 2022.2 beta but few others and I have tested it and it's bs.
    I made a bug report & 2 threads (main one) and 0 replies nor has it been addressed in releases for more than a month now.
    If only they had an internal project like Gigaya and not cancel it years ago we wouldn't be here discussing about dipping iteration & productivity time.

    Mobile microtransaction services are more important now than the company's flagship product it seems.
     
    trombonaut, V5Studio, bobby55 and 2 others like this.
  21. Darkgaze

    Darkgaze

    Joined:
    Apr 3, 2017
    Posts:
    397
    Would separating the code in a lot of assemblies, with the proper independency and the correnct attachment of only the referenced assemblies improve this? I'm assuming it does, A LOT. But not really sure.
     
  22. maxter23

    maxter23

    Joined:
    Oct 29, 2014
    Posts:
    8
    Unity 2019.x, 2020.x, 2021.x, 2022.x all were slow on my home Windows PC but worked great on my office Windows PC.

    By slow I mean that empty freshly created project with one script in it took 15 second for Unity to process the change to a script ("Hold on" "Reload Scripting Assemblies") and 10 more seconds after pressing Play button to actually enter Play mode.

    HERE IS HOW I FIXED THIS ISSUE:

    My office Windows PC System Language was to English US and my home PC was set to Ukrainian.
    By setting your Windows System language to English US the issue is gone.

    Unity team, can you confirm reproducing this bug with any other non-English language setting?
     
    Natink likes this.
  23. Darkgaze

    Darkgaze

    Joined:
    Apr 3, 2017
    Posts:
    397
    I think you should ping somebody. But yeah, that's interesting. Mine is set to English US.
     
  24. DraxThemSklounst

    DraxThemSklounst

    Joined:
    Feb 1, 2021
    Posts:
    5
    I went to double check if this was my issue. I am set to English US and my compile times just to play are reaching 40+ seconds. I get why unity needs to look through everything, but to me taking 40 seconds is getting extreme. Unity never used to do this back in 2019, but then is when Unity would actually respond to bug reports and their forums. Is this silence the new norm with this merger or are they going EA on us and only going to focus on Micro Transitions?
     
  25. AnimalMan

    AnimalMan

    Joined:
    Apr 1, 2018
    Posts:
    1,164
    Yeah reloading script assemblies is a joke. I go ahead and remove all of the the built in packages except 1 or 2 essential packages. Sometimes it improves iteration time after you reload the project. Another tip is to disconnect from WIFI and internet. as it seems most of the time when i am disconnected from wifi and internet, that unity doesnt slow me down so significantly much as it actively tries to do on brand new empty projects that use default packages and settings.
     
  26. kemijo

    kemijo

    Joined:
    Apr 7, 2014
    Posts:
    18
    Someone posted a workaround for this somewhere and so far it works every time for me. My tiny project very suddenly started doing this as well after hitting play, 'reloading script assemblies' as long as 30 minutes sometimes. Now once it says "busy", I just hit save in an open script in my IDE (I'm using VS Code). Doesn't matter if there are no changes to save. 1.5 second after hitting save the reloading progresses as normal and the game enters play mode. Hopefully this works for some of you.
     
    Last edited: Sep 16, 2022
    WillowGames likes this.
  27. Homicide

    Homicide

    Joined:
    Oct 11, 2012
    Posts:
    657
    This 100% - it really feels as if unity has become more difficult to work with in some ways over the years.
     
  28. AnimalMan

    AnimalMan

    Joined:
    Apr 1, 2018
    Posts:
    1,164
    Perhaps other problems existed. Such as crashes and loss of data. In 2019 we did not have these modern issues but we had a lot more crashes data corruptions scene corruptions etc

    you need to remove unnecessary packages and then restart the editor.
     
  29. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    Removing everything possible and restarting doesnt make the problem go away in larger projects. Unity needs to cache things that dont need to be reloaded, and..... not reload them.

    Reloading everything all the time makes things more stable and cleaner, but give me an option to turn it off and ONLY reload the non asmdef code that isnt changing.

    Then I would go from 30s every time I change 1 line of code, to 3s, and I can maintain productivity.
     
    trombonaut and AnimalMan like this.
  30. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    1,066
    Reloading assemblies has been in Unity forever. Unity added a progress bar around 2020.2? that makes the stalls move obvious.

    At the same time, more engine code is moving from C++ to C# inside packages. This increases the number of managed objects Unity has to reload and the amount of code that runs when doing so (InitializeOnLoad et al.), which has increased reload times.

    A partial reload is not possible. In Unity, all code can interact with any other code, e.g. editor code can directly access gameplay code – and the other way round. If anything changes, and with the safety guarantees of C#, Unity has to serialize all Unity objects, reload the app domain with the new assemblies and then deserialize/initialize all those objects.
    The only way around this would be to have multiple domains, that can then be reloaded independently. But that would mean managed objects in different domains could no longer access each other directly and would have to use more complicated communication mechanisms.

    Splitting code into separate assemblies potentially reduces compilation time. But compilation time is usually pretty quick. As outlined above, if any assembly changes, all managed objects have to be reloaded, so multiple assemblies do not reduce reload time.

    Unity has added options to skip the reload when changing play mode. The reload there is done to provide a clean slate when entering/exiting play mode and can be skipped if the code takes care of cleaning up itself. However, when the source code or assemblies have changed, a reload needs to happen for the changes to take effect, it cannot be skipped.

    Since reloading involves all C# code including packages, slowdowns can come from countless sources and there's no single fix. We might see some general improvement with or after the upcoming upgrade to .Net 6+ but for now, improvements are made by fixing/optimizing the countless parts that take time during a reload. Wether fixes/improvements Unity has made apply to your project is highly dependent on the project and wether you happen to use the relevant parts enough. Unity has added domain reload timing to help diagnose where the time is spent in your project, see here how to enable them.
     
  31. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    Skipping reloading the domain on play was a great feature, but is not the problem here. This thread is about reloading the script assemblies.

    If the non-asmdef code changed, but the script assemblies did not change, then it may be unsafe to not reload them, but give me an option and let me deal with the editor crashing if I break something the script assemblies need.

    In my project, the script assemblies are their own things, and my non-asmdef code uses them, but not the other way around. I think this is the normal case. I am not changing them, and they are not accessing my code.

    Unless the method of compilation absolutely does not allow this, and I dont have the C# compilation expertise to know that, but using a DLL comparison, the old DLLs absolutely can be cached, and not reloaded, and any mismatch would cause a crash, but if there is no mismatch, then everything would work fine without any of that work that I am constantly sitting through for 30s at a time, every few seconds of progress I make.

    C++ compilation absolutely does not have this problem, and maybe C# is written in a way where thats impossible, but my current assessment is this is safety over speed, and thats great, but it massively hurts my productivity, so if its at all possible, give me an optional to disable script assembly reloading (with manual button or API call to do it) and if it starts crashing, I know how to fix it by turning it back on. But none of my script assembly code ever touches my non-script assembled code. Its always 1-way access.
     
    StellarVeil likes this.
  32. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    1,066
    @ge01f What Unity shows as "Reload Script Assemblies" is a domain reload. The compilation itself is shown as "Compiling C# Scripts" but, since Unity upgraded to a recent version of the Roslyn compiler, it's usually pretty quick.

    Unfortunately, the separation with asmdefs / assemblies only applies to the compilation, where only dependent assemblies are recompiled on a change. But for the changed code to take effect, the domain has to be reloaded. And since everything in Unity is in a single big app domain, everything must be reloaded for every change.

    And yeah, it does come down to the difference between C++ and C#. In C++ you can reload some DLLs and, as long as the memory layout hasn't changed and you're careful with some pitfalls, your program can just continue with the new code. But C# is a managed language and comes with safety guarantees that make this impossible. In C++ you can directly access memory and do whatever you want, in C# you're confined to the language and don't have access to the low-level details of the runtime. C++ has undefined behaviour but leaves it up the developer to not shoot themselves in the foot, C# simply doesn't allow almost anything that it cannot prove is safe.

    Unity has been moving towards general .Net compatibility, so I don't see them adding custom hot code reloading to the runtime. Microsoft is working on what they call Edit & Continue but Unity first needs to update the runtime (the player runtime will be in 2023.2 at the earliest as an option and the editor runtime will probably follow at least few releases later) and it currently is pretty limited.
     
    AldeRoberge, kayroice and ge01f like this.
  33. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    Thanks for the detailed information. Its unfortunate its not going to be fixed in a number of years, as I will probably spend several months of that time waiting for scripts assemblies to reload.

    I appreciate the information though.
     
    jehk27 likes this.
  34. AnimalMan

    AnimalMan

    Joined:
    Apr 1, 2018
    Posts:
    1,164
    your assets don’t need to be in your unity project folder. If you have no other option but to use Unity. As is a similar situation as me right now, Pull the assets from a directory as part of your games launch. If you keep your files in a directory that you reach for development; for example; on the desktop; then you won’t have to reload those assets. Yes this can be awkward, but it saves Unity iterating through every asset you have. You can grab files from directory outside of Unity no problem and load them into your game. And leave Unity project folders virtually empty aside a few scripts.

    just an idea. Won’t help if you are deep into a project already without this aspect planned for. But for future projects it may be a good idea.

    in the context of Unity software this solution is counteractive to the asset store goal of selling you every asset you need and clogging your games project folder with assets. Since that kind of practice will result in huge reloading times. With 30gb of assets in a directory on your desktop and loading them into your game on launch then you are one step towards having complete control over editor performance and development.


    Maybe this will help

    https://docs.unity3d.com/2019.4/Documentation/Manual/AssetDatabaseRefreshing.html


     
    Last edited: Sep 19, 2022
  35. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    Thanks for the tip! I hadnt seen this before. I have about 150GB in my unity assets now, but it doesnt seem to be a problem unless I do something that causes an entire re-import, which I almost never do. For me, its just the script assemblies reloading that are a problem.

    This project is close to launching, but still has 1-2 years more I want to work on it. If Unity hasnt fixed the problem by then I will probably just invest into learning Unreal or whatever is best then. Its a shame, as Ive gotten used to Unity in a lot of ways, and Im sure Unreal has its own problems, but Im willing to put in the time to test them to get away from waiting on script-assemblies reloading for the rest of my life. I like to actually work when Im working. Compile time delays used to be a thing of the past.
     
  36. AnimalMan

    AnimalMan

    Joined:
    Apr 1, 2018
    Posts:
    1,164
    So let’s say you have a skinned mesh renderer and you used the Unity animation system to animated your models. But you can’t keep your models in the project folder due to this issue, how to go about having animated models using unities animation system?
    well if the game featured a humanoid bone structure and an quadruped bone structure for example you would keep only one or two guide models in there. So that you could make animations in these systems but still load models with matching armatures from outside of the project folder.
    That is of course if the size of the project folder is the source of the issue.
    On my original suggestion I said to remove some of the unused packages, now it’s worth checking if you have two packages that are for VS studio, and if you do, one of these packages can be safely removed without preventing usage of VS studio.

    anyways buddy I know it’s frustrating. I have debated a switch to unreal many times for a long time, but it’s the unknowns of the engine that I fear. There are also other engines to consider such as Source, who are not a stock market based company. And therefor less prone to being managed or orchestrated by somebody with lots of money financial incentive but no skill in actual development. But anyways all the best, I do hit this issue with every brand new project and some project prep has to be done to optimise it at the earliest stages but it never ceases to frustrate me. I hope you can figure out a workaround or maybe Unity will improve the timings or at the very least allow you to go back to older versions in the future. All the best
     
  37. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    Thanks! It's really just about reloading all the code, not assets. Im doing a fairly large open world game, its got a lot of code, and assets. But the assets arent the problem, its just reloading the script assemblies. Compiling the non-asmdefed code is fine, loading assets is fine, but reloading script assemblies takes 30s, and that just burns burns burns time.

    If I move, I wont move because Im frustrated, I'll move because I need to be productive and watching "Loading script-assemblies" dialogue all day is not productive. On smaller projects, this shouldnt be an issue, but there are quite a lot of things Unity does not do anything about when it comes to very large problems. Everything else so far I have found workarounds for, but this one I have not.
     
    trombonaut likes this.
  38. AnimalMan

    AnimalMan

    Joined:
    Apr 1, 2018
    Posts:
    1,164
    How many scripts specifically do you have?

    Because I know it tells us that it is reloading script assemblies but just because that’s what the bar says it’s doing it may not be what it’s actually doing. From my understanding the reason scripts are reassembled is because all scripts go into a DLL and any change causes a complete recreation of that dll. And the cpu can usually combine text files pretty quickly like it shouldn’t be a problem for anyones cpu to do that unless you have thousands of scripts. but obviously Unity tells us or at least indicates with the loading bar that it is the problem area. But I am not that type of dev yet I don’t know what they are dealing with back there, and if they are designing it in ways where only certain devs are qualified to make these repairs due to unnecessary or unusual coding practice whereby one dev might just give another dev the run around in order to compete for a position of authority or higher wage salary or to take higher value in their service. But bro if i delve any further into this type of conspiracy il get in trouble.

    have a test on a new blank project. Remove the packages of no use such as jet brains. Or duplicate vs packages. Save Restart Ed check iteration time. Then add empty scripts or jargon scripts one by one until you break it. If you can’t break it then something else is the cause. Which may be why Unity doesn’t seem to know how to fix it Or is not willing to fix it.
     
  39. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    I have 5209 scripts in this project. All of those are in asmdefs except for 355 that I compile each time.

    Since the project is nearly launching, I cant really spend a lot of time taking it apart and playing with which I can live without. I spend weeks of time doing that.

    Some of the scripts are utilities that could be in another project, but then I have to having multiple projects and import assets between them, and a lot of the utilities still have in-game components that are needed, and were designed to be split up. So it's really not an endeavor I think would be productive.

    My assumption was also that these asmdefs get bundled into DLLs, and dont need to have anything done to them except reload them, as they are already compiled, and they shouldnt take 30s to reload, but there just isnt enough information to know why its so slow.

    I'll finish my project, and maybe I can find a way to speed it up, and if I cant, Ill just switch engines for the next project so I dont spend my life waiting. :)
     
  40. Homicide

    Homicide

    Joined:
    Oct 11, 2012
    Posts:
    657
    Sure feels like it sometimes.
     
  41. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    1,066
    Yeah, I do hope Unity will do the grunt work and continue to fix and improve the reload time as well as be watchful that changes don't regress it. There won't be a dramatic improvement anytime soon but there will hopefully be significant incremental improvements until then.

    One thing I would recommend and that shouldn't take too much time is to look at the domain reload timings Unity has added. It might not help much, if you e.g. just have too many objects that need to be saved and reloaded, but there might be an outlier in a specific package or asset you're using and with the timings it should be easy to see. In Unity 2020, timings are available from 2020.3.14. They need to be enabled by setting the
    UNITY_DIAG_ENABLE_DOMAIN_RELOAD_TIMINGS
    environment variable and then appear in the editor log.
     
    ge01f likes this.
  42. AnimalMan

    AnimalMan

    Joined:
    Apr 1, 2018
    Posts:
    1,164
    5029 scripts is pretty huge.


    I get 15 seconds of assembly on an empty project before removing visual scripting package and the other packages.
     
    AldeRoberge and ge01f like this.
  43. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    Ive removed everything I can. Any builtins or unity registered packages I remove now cause a compile error, or dont allow it because something I use needs it. I went through and tried each one again, and Im as lean as I can get on those, but there are still a lot of them unfortunately. Some I dont think though be there, but Im not going to go ripping through code to try to get them out. Better to just release and deal with cleanup later if it's worth it.

    I'll try that, thanks! It would be great to find some of the single-blocker type problems and possible just eliminate those.. Ive had a few of those before that would do things like make a TCP connect and wait 40 seconds before timing out, but hunted those ones down before.
     
  44. WillowGames

    WillowGames

    Joined:
    Aug 15, 2017
    Posts:
    1
    This actually worked, thank you so much!
     
    kemijo likes this.
  45. Seltzer

    Seltzer

    Joined:
    Jan 21, 2015
    Posts:
    5
    I haven't managed to eliminate the problem, but I've reduced it significantly. I've had this problem frequently in versions 2019 all the way to the most recent LTS (2021.3.11f1 is what I'm using at time of writing). I haven't tested with 2022 versions.

    Symptoms: Upon assembly reload, sometimes it'd hang indefinitely and sometimes it'd take around 7-15 seconds, even in a large project. There didn't seem to be any correlation with number of changes or number of scripts. There's no way it's a project size problem.

    General Observation: The more places that trigger a reload, the more likely it was to hang. Anything you can do to avoid triggering that multiple times reduces the chances of hanging. I can't consistently repro but there's definitely a correlation for me, so I suspect it's some kind of synchronization bug. Maybe a deadlock or livelock?

    Here's what I've done that seems to make it more stable:
    1. If your IDE has an integration that auto-refreshes assets, disable that. If you're using Rider integration, go into the Rider's Unity settings and disable automatic refresh. Not sure if VS has an equivalent to this, but disable that if it does.
    2. In Unity's General preferences, set Script Changes While Playing to Stop Playing And Recompile and Busy Progress Delay to the highest value possible.
    3. In Unity's Asset Pipeline preferences, set Auto Refresh to Disabled and uncheck Directory Monitoring.
    4. Edit: Someone mentioned in another thread that disabling editor analytics helped their refresh time, which I just remembered is something I also did that may have helped somewhat. I remember it didn't much impact the hanging for me, though.
    Note that it may be that not all of these are necessary. Some of them may just be acting for good measure, since I can't know for sure what they're doing internally, and it's hard to be certain about frequency without spending many hours testing permutations of these.

    It still triggers automatic reloads when re-focusing the editor after code changes, and triggers yet again when you Play regardless of whether you changed anything, but it takes way less time and tends to hang less often for me.

    Also note that it seems the editor doesn't even fully respect these settings, and it still hangs regularly, at which point it's faster to restart Unity than wait for it to unlock for some indeterminate amount of time. Still, I've seen a marked difference in reload time and frequency of hanging now.

    Maybe there are more things that can be done with editor scripts? Maybe newer versions of Unity have additional settings that'd help? If anyone knows of more improvements I can make to this please reply!
     
    Last edited: Oct 3, 2022
  46. normand

    normand

    Joined:
    Mar 18, 2014
    Posts:
    11
    ''RESOLVED'' Preferance-->Analysis-->Default editor target on start--->> change Play mode to editor. :p I just did what the first answer comment on the to top... lol
     
  47. ABerlemont

    ABerlemont

    Joined:
    Sep 27, 2012
    Posts:
    67
    Is this related to reloading scripts assemblies ? this is to modify some play mode of the profiler.
    https://docs.unity3d.com/Manual/Preferences.html
     
    Last edited: Dec 16, 2022
    SirhotBay likes this.
  48. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    It looks like a good tool, but it also looks like the language/compile limitations make it unsuitable for me. I will almost always change public facing functions and add new fields, unless I am just tuning. If Im tuning, I can just slide the variables around and save them in-game. If Im fixing things, it's too difficult to figure out whether this would be useful for the limited cases where Im not touching public functions or adding new variables.

    Im sure for some people this is a good work flow, but for me it doesnt match what I normally do when I am changing my code. I appreciate that you made this though. If my work flow changes later and it seems more viable I will buy it.
     
    ChrisHandzlik likes this.
  49. ChrisHandzlik

    ChrisHandzlik

    Joined:
    Dec 2, 2016
    Posts:
    205
    @ge01f thanks for letting me know - limitations are definitely a pain right now. The goal is to make it align with our workflow as close as possible.

    I think getting new fields working is possible, methods pose some more challenge - but hopefully doable
     
  50. ge01f

    ge01f

    Joined:
    Nov 28, 2014
    Posts:
    121
    I think new fields would go halfway the distance, and make this worth trying in my workflow now. Then I would only really be missing the public functions updates, and if this was my work, then I could just wrap private functions I wanted to work on to make the process work live.