Reducing Compile Time in Unity Using Assembly Definition Files

Academia has gotten so big that its compile time is so horrendous at around 60-100 seconds. I’ve done everything I could like moving third party assets and our common framework to Plugins folder. I’ve even move the project to a solid state drive. This is why Unity’s new feature named Assembly Definition Files is music to my ears. You can create an asmdef file in any folder. Any C# code in the folder and its child folders will be compiled to its own dll. This means that the source files in the folder will be skipped during recompilation if there are no changes in it or on any of its asmdef dependencies.

I’ve been using this feature for weeks now. I’m still not done. I’m still making asmdef files on the project’s many source files. It wasn’t as easy as I thought it would be. You can’t just create a definition file on a folder and expect everything to work. After lots of trial and error, I’ve developed some sort of a “process” when creating these files. I imagine making asmdef files like fighting zombies. The zombies here are the source files that has not been collected to an asmdef yet. By making asmdef files, you convert these zombies to fight for you. What I mean is if you successfully make an asmdef file, you can use that file as dependency to future asmdef files. As you make more of this asmdef files, it gets easier to convert more zombies to your side.

One at a time

When I first started using asmdef, what I did was I created these files all over the place whenever I can. When I see a compile error, I make an asmdef on those files hoping that it will be fixed. Boy was I so wrong.

What worked for me is to create an asmdef file only after all compile errors are fixed. There’s bound to be errors because you may not know the dependencies of the source files in the folder. Once you’ve “elevated” a code to an asmdef, they expect that their references are also in asmdef. It’s a good practice to create asmdef files from folders with zero dependencies to ones with more.

Start with third party assets or frameworks

This is kind of obvious as third party assets don’t have dependencies to your project (unless you hacked them and added a dependency to your code). These asmdef files shall be your army when you begin attacking your game code.

From generic/common code to specific code

When you start making asmdef files to your game code, identify which are the generic/common code that any of your game’s systems can access but does not have references to any such systems. Isolate these code to its own folder and create an asmdef for it. Add third party asmdef files as dependencies if necessary.

From here, identify the next group of code with least dependencies and make the next asmdef on such folder. The existing asmdef files can be used as dependencies. Attack from least dependencies to ones with more.

Special case for editor scripts

You can create asmdef files for editor scripts. Just make sure you don’t mix non-editor scripts in its asmdef. Also ensure that you alter its settings such that it’s only included in editor platform. This can be done by unticking Any Platform and ticking only Editor under Include Platforms.

Fast compilation? Not always

I have over 70 asmdef files now (more will come). Overkill? I don’t know. There are projects out there bigger than ours. There’s certainly an effect on compilation time but it depends on the code. If the code is on a common/generic asmdef such that it’s required by numerous other asmdef files, the compilation time is the same or even slower. The compilation time is only faster when only specific code has changed. The more specific the code, the faster the compile time is. Hopefully, we spend most of our time on such code. These are mostly new features and specific game systems. Generic code are supposed to be stable. They should not change much.

Side effects

One side effect when using asmdef that I like is enforced dependencies. Now you get compile errors when you try to add a reference of some code that was not defined as a dependency.

A side effect that I hate is slower Visual Studio loading time. Each asmdef is considered as a separate Visual Studio project. Whenever you move code to a different folder or create a new asmdef, the IDE reloads which means it has to reload all of those 70+ Visual Studio projects that I have right now. Opening the IDE for the first time also does this. It’s annoying.

Like my posts? Subscribe to my mailing list!