Question Current stage of the "Reload Script Assemblies" problem in 2023

Reload Script Assemblies time grows more and more with the project growth. It has been some time since it started to be a problem for me.

The first solution I found was to disable auto refreshing, so I can manually do Ctrl+R to compile + reload script assemblies only when needed.

Time has passed, and reload time increased such that, even with manual refreshing, it is still problem. I have now 30-35 seconds of reload time + 15-18 seconds to enter play mode. The time itself is not that much but when you have to make a lot of minor changes to the code, it becomes a huge difference. There is also the psychological impact of not being fully focused on the task due to these constant pauses. In the end, this is a big productivity killer.

I looked again for alternative solutions but none worked well (or were feasible).

I aimed at reducing assembly definition files since the compile time they save may be compensated by reload script assemblies time. I did some tests, didn't work well, so I gave up this path, since it seemed unfeasible.

I also saw that you can disable domain reloading to decrease enter play mode time (which comes altogether with the script assemblies problem), but then I have to look for all static fields of all code and create "special" initialization functions for them (not feasible), so they may be reset when entering play mode.

I also tried this asset to apply code changes at runtime but it is very limited and also didn't work well for me.

So my first question is: is there a solution (at least a mitigation) for this problem? I am using Unity 2021 LTS, does it improve in Unity 2022 LTS?

Also, does Unity staff is aware of this problem and have some plan to improve this situation?

EDIT: Here is some info about my machine specs and the project.

SO: Windows 10
Processor: AMD Ryzen 7 3770 3.6Ghz
Video card: AMD Radeon RX 5700 XT
RAM: 32 Gb
SSD: Kingstom SA400S37960G sata 3

Assets folder has 108 Gb. It has 3031 .cs files in total (counted using dir /s /b *.cs | find /c /v ""). From my own code I have only 175. Total lines of code on all .cs files on Assets folder is 612k (counted using find . -name "*.cs" -exec cat {} \; | wc -l).

 

Not really.

Not really.

Yes.

The plan is hope that CoreCLR fixes the issue for them but we're multiple years away from that, and in the meantime things will probably keep getting worse.

 

Thanks.

Anyone else?

Regarding domain reloading, it is not much clear to me what is the scope of the static fields interference. Do I have to look at static fields of Unity packages (like Localization, Input System)? Or maybe just scripts in the Assets folder?

 

The actual code compilation part of a domain reload (the proper title for "Reload Script Assemblies") is a very small part of it, and does mostly happen asynchronously. The actual spaghetti-and-meatballs of a domain reload is a whole slew of other things that depend on a lot of other factors. You can see what these steps are and how long they take by looking at the Editor.log file.

First advice I can give is to ditch all the unnecessary packages you don't need that come with project by default. Packages like Shader Graph and Visual Scripting are huge, and if you don't need them, bin them. This can make a big difference.

Naturally most of the work here needs to be done on Unity's end but there are times when something on the user's side is eating up seconds during a reload.

There's a tool to profile domain reloads: https://forum.unity.com/threads/introducing-the-editor-iteration-profiler.908390/

Might be useful to see where most of the time is taking and might lead you to steps to reducing/mitigating any potential culprits.

Other than that, honestly, hardware makes a big difference, but that's not a feasible option for most people.

 

I have never, ever seen domain reload taking 30 seconds or more UNLESS there was something seriously wrong with the project.

That's not to say there can't be cases where everything is alright, the machine is super fast and it still takes that long - but this always makes me suspicious because every time in the past we had a problem like this, it was our fault and it takes some analysis but it's definitely doable to pinpoint such issues and possible solutions. Sometimes it's just that one thing, more likely it's a combination of many smaller issues and typically due to bad software architecture decisions (read: wut artichecture?).

My favorite: editor scripts! Those that hook into AssemblyReloadEvents and perform stuff that is really, reaaaaaally bad performance wise, like iterating over all assets in the project, doing a little thing to each one they had to do something with, and then calling AssetDatabase.Refresh() after EVERY SINGLE ONE OF THEM!

Needless to say, this is one of the reasons why I wrote this post about AssetDatabase.Refresh(). When your domain reload time goes significantly over 10 seconds on a reasonably beefy system you should definitely check whether you have an issue with editor scripts, or as spiney mentioned: too many assets/packages.

Sometimes it can help noticably if you move 3rd party assets which did not come with a Assembly Definition file for their scripts to the "Assets/Plugins" folder so that they're automatically compiled into a different assembly.

I would appreciate if you could share your system specs so that others can put your report into perspective. Also whether you see any differences, and which, on other machines with notably different specs.

We also know NOTHING about your project. How big is the Assets folder for instance? How many .cs files are under Assets and how many lines of code in total? That would also help put things into perspective. If we're talking a few GB and perhaps 10k lines of code - you got one of the issues above. If your project is dozens of GB and >100k LoC then perhaps you just have a huge project (but you can likely still optimize those domain reloads).

PS: the first thing I do in every new project is to disable domain reload! This is soooooo fast and the static issues so easy to fix, in fact, it prompts you to avoid static references/delegates altogether which is good practice anyway.

 

The Reload Script Assemblies after compilation counts as domain reload? When I said domain reload I meant the enter play mode time.

Well, the reload time was gradually increasing along with the project development, with each new package imported and each new .cs file. So it seemed natural.

What is wut architecture?

I have only 2 editor scripts of my own (added few weeks ago) and they don't do this. They simply create editor windows with some fields and buttons that perform tasks when clicked. Still I have the impression that reload time increased 1-2 seconds after them, but not sure. I don't use AssetDatabase.Refresh(). I don't iterate all assets in project but there are some few scriptable objects that iterate files on specific folders, but I never noticed this as a performance problem.

I will try this.

SO: Windows 10
Processor: AMD Ryzen 7 3770 3.6Ghz
Video card: AMD Radeon RX 5700 XT
RAM: 32 Gb
SSD: Kingstom SA400S37960G

Assets folder has 108 Gb. it has 3031 .cs files in total (counted using dir /s /b *.cs | find /c /v ""). From my own code I have only 175. Total lines of code on all .cs files on Assets folder is 612k (counted using find . -name "*.cs" -exec cat {} \; | wc -l).

Do I have to look at static fields of all .cs files in the Asset folder? I have a lot of third party tools.


I think I will have to do a cleanup in the assets and packages, to make sure everything that is on Assets folders is really necessary.

 

There is also the matter of assembly definitions. I don't use them in my code, but there are .asmdefs for some third party codes. Can they improve reload script assemblies time? If they are simply going to improve compile time then they won't make much difference since compile time itself is fast (max 6 seconds).

 

So are you just talking about how long it takes Unity to recompile? Or the overarching domain reload?

Like I said, the code compilation part is only a tiny portion of a domain reload. Assembly definitions don't make a difference honestly.

 

Thanks for sharing these details! Over 100 gb assets and 600k loc makes this quite a huge project. I would not necessarily expect a project of this size even from a AAA studio. In fact, they may be adamant to keep their project‘s scope in check as any delays would affect dozens of devs on a daily basis.

Perhaps you simply crammed way too much into it? One way to find out is to use the Asset Hunter asset, but Unity provides some tools and logs too. There is a Build Reporter/Analysis tool for instance.

Disabling domain reload will be a tough one after the fact. Yes, every third party script needs to be (made) compatible too. That is why this is the first thing I enable in every project.

Exactly!

I wrote it the way I wrote it to indicate that perhaps no thought was given to software architecture concerns. This is particularly rampant with Unity projects, and can bring them down easily, not just slowing down development, hindering performance but in fact killing the project because it becomes unmanageable and hard to extend and creates ever more inexplicable bugs as work continues.

 

Thanks. I don't use all of these assets at the moment. So I did a cleanup (aimed to code) and it almost halved the number of .cs files. I have now about 23-26 seconds of reload script assemblies time. I also deactivated domain reload and did the required changes in my code. However this is not much reliable so I am using with caution.

I still don't understand how software architecture could be causing this in my particular case. I always try to reuse code and be minimalist with it, the same regarding the number of classes and (mostly) .cs files (of course there are third party code, but I am talking about my side.). I understand that these are the reasons why software architecture could cause the reload problem, but, are there more?

Also, most of the code is third party, and you mentioned before something about placing files in the plugins folder. It is just as simple as that? Is there anything else I should know about this folder?

 

That's not what software architecture is about.
SA is about defining modules, systems, how things connect and communicate and in which direction, boundaries, design patterns, programming principles and so on.

 

What I said is really part of software architecture and is part of what you said. Following software engineering good practices will (tend to) lead to modularity and code reuse, which will lead to less code. And, as far as I know, it is the amount of code and files that will impact in reload time, not software architecture by itself.

 

UPDATE: I finally found the big bottleneck of reload time: UMA Global Library and a lot of Wardrobe Recipes on it. I did a cleanup and let only the wardrobes I am really using and now I have 13 seconds of reload script assembly time.