Solution to reduce Script assemblies reload time & iteration time

Unity Engine
,
1

I’m sharing here a nice solution I came up with while thinking about how to reduce painful iteration time. If your script change iteration time is less than 6 secs you are probably better off without this but you can try.
Make a backup of your project and try the following on the copy or original:

#if FEATURE_X
...
#endif
  • Done.

To renable an asmdef you simply have to remove the “!” or any character you chose next to the define if you followed my method.
I searched a lot on the net and yet not a single person gave an accurate working solution to this problem or thought about this one and tbh I’m baffled considering this issue has existed for more than 2 years and not even the UT staff suggested it to my knowledge (simply putting code in asmdefs alone doesn’t help) and yet in less than 2 days I discovered define constraints’ usefulness & came up with this neat lil trick once I finished measuring each plugin’s impact.

Note: not all dependencies/assemblies have a significant reload time impact, you might wanna measure to choose which ones are worth the trouble to disable if you have a significant coupling to particular ones in your code.
Make automatic backups of your project’s main data that’s stored in components/scriptable objects that are subject to being disabled by this process in case of data loss though it only happened to me once and can’t say whether it was due to a crash, this trick or something else.

In my case I was able to reduce the reload time by ~2.3 secs from ~9.6s down to ~7.34s by literally disabling about all but 2 lightweight plugins and 1 for improved hierarchy that although has an impact is still worth keeping for quality of life purposes.
I wish I could reduce it further but you may have bigger benefits because I had already reduced the reload from 17 secs previously to ~9.6s by straight up removing several plugins & packages from the project though now that I discovery this trick I’ll reimport then and use this instead.

Another tip is reducing enter/exit playmode times by doing your iterations on a minimalistic scene, in my case it takes < 1 sec to enter playmode that way.
Compare ~17s script change time + ~15s for enter play mode + ~2s for exit to ~7.5s + < 1s + < 1s for iteration time.

If I make any other beneficial discovery I’ll make another post and link it here cuz this one already gotten long.
Hope this helps, I know for fact it works because disabling impactful asmdefs prevents their .dll assemblies from being generated in your Library/Script Assemblies thus their reload time but whether you can apply it for certain assemblies depends on your level of coupling to them.

Make sure to share this link to reduce this huge daily pain for everyone using Unity whenever this topic is brought up until UT finally releases a proper practical solution 2+ years later, hopefully sooner**.**

2

It doesn‘t help if most of the code relies on code that changes frequently. It does (or should) help if you modify only code that is part of an asmdef and said code is not referenced by any other code. In that case you will (or should) notice a benefit compared to not using any asmdef.

What you are suggesting sounds a lot like assemblies that are not well seperated. If it were you could simply remove an assembly from the asmdef references rather than using conditionals to remove „features“.

Having to work with preprocessor conditionals is dangerous as it can waste time elsewhere, especially when you run into bugs, try to debug them, only to find that you (or someone else on the team) forgot to remove the conditionals. Or shipping an update with a feature accidentally disabled.

3

PS: if you can, try upgrading Unity. Unity is making incremental improvements to turnaround cycles and that‘s been noticable for me going from 2019 to 2020 and 2021. Also consider the „Enter Play Mode“ options. It‘s also good practice as it encourages you to stay away from static variables respectively using them carefully.

4

Alright there’s a lot of erroneous stuff to debunk here.

I’m talking about dependency assemblies of non-changing code e.g plugins/3rd party, referenced or not so no, putting them into separate asmdefs does not help reduce Script Assemblies Reload (SAR), I’m not talking about compile time there’s a difference.
Most of my codebase does not reference code that changes frequently.
When you have non-referenced non-changing assemblies in code they still increase SAR time (not compile time) because their .dlls are still in your Library/Script Assemblies folder and get reloaded anyway by Unity.
The solution I’m proposing is to disable non-vital features or tools that needlessly increase your SAR time while working on unrelated features.

2nd this also involves heavy hitting assemblies like game design plugins, tools/systems that you don’t use all or most of the time (depending on your role/phase) or when working on unrelated features and you don’t need them and yet they still bloat the SAR time.
So you could benefit significantly if all you want at a given time is work on a part of your own codebase without unused/unneeded dependencies or 3rd party bloating the iteration time.

Speaking of conditional compile I only had to make a few cuz as I stated they’re loosely coupled parts of generally non-changing code and they do not impact the rest of the codebase thus not subject to break.

Again I’m talking about big dependencies/plugins/3rd party assemblies which you can put into as many separate assemblies as you want it will not reduce SAR time.

If you remove a dependency’s asm reference then you still end up with compile errors of missing references so in the end you’d still have to use conditional compile or be unable to use the dependency which defeats the whole concept of “dependency”.
It is much easier to cut ties with external dependencies that only seldom get referenced in my code and seldom changed when I don’t need them as I work on unrelated features than splitting my own codebase into various assemblies which is harder to do and can complicate things further when you work on complex sizable projects (AA+ projects).

When you need to change a dependency you’d have to renable it to check the changes thus the conditional blocks would be enabled to reflect the changes.

PS I’m literally using the latest Unity version 2022.1.6f (before 1.7 recently came) where no benefits whatsoever to SAR time have been recorded after countless hours of thorough benchmarking across versions 2019 LTS, 2020.1.17f1, 2020 LTS and 2022.1f.
I did notice a decent decrease in the alpha 2022.2a but it’s unusable atm ( Bug - (IN-8232) Disabling Roslyn analyzers makes all MonoBehaviours unusable in Unity 2022.2.0a17 - Unity Forum ).

When you disable a whole dependency assembly it means even the components from that asm are disabled in your inspector and you don’t see their impact/effect while testing the game so it is pretty conspicuous when one such asm is disabled and hard to miss.
I did also leave a warning about this topic and stated that this is to be used with loosely coupled parts of code i.e code that isn’t subject to break if something changes elsewhere or at least minimally:

I’ve been using that feature the moment it was introduced in 2019 beta til this day, it’s a no brainer for any serious project and that only concerns enter play mode time which is not the main topic of this thread which is SAR time and I mentioned that it takes < 1 s to enter play mode which in a sizable project cannot be achieved without those options even on an empty scene.

5

Further clarification on this point, you don’t have to remove any conditionals you just enable or disable an entire assembly by simply changing the define symbol in ProjectSettings > Player and that’d subsequently enable/disable all its related conditional blocks.

Disabling the assembly not only automatically disables those code blocks (which’s visible as grayed out in your IDE) but also any component from that assembly so it’s quite clear that the asm is disabled whether you’re testing in play mode (presence of its effect), working in edit mode (inspector) or on related code inside the IDE (grayed out).
Or you could simply have a look at your Scripting define symbols list and read the define which is the easiest thing you could do effortlessly without custom editor scripting.

6

One additional inconvenience is that if you make changes to a prefab that has an excluded component you’d have to renable the comp’s assembly in order to save the changes.

7

Having conditionals which affect serialized data is quite dangerous and can easily lead to data loss.

8

Haven’t had that issue so far even after having enabled/disabled some assemblies multiple times and as long as I have daily data backups (like anyone should) I have no problems.
Having a faster iteration time is like having working AC during heatwaves in terms of quality of life.