Mad Compile Time Optimizer is taking an advantage of Unity special folders and how Unity compiles things.

If you’re already familiar with this matter then you most probably know that moving your scripts back and forth can take a lot of time. What’s a bigger problem is that you almost always have to do it each time when you want to upgrade assets from the Asset Store.

What does a programmer do when he needs to do something repeatedly? He writes a script to do it of course! That’s why Mad Compile Time Optimizer has been born!

Why the optimization works?

Let’s say you have two scripts: the Foo.cs script and the Bar.cs script. Both of them are placed directly in Assets folder. If you modify the Foo.cs script, Unity will compile both of them. The same goes for the Bar.cs script.

Let’s say that you want to optimize your compile times right here. There are two conditions these scripts need to met before optimization can be successful:

  • The dependency should be only in one direction (either Bar.cs → Foo.cs or Foo.cs → Bar.cs)
  • The script that is the dependency should not be modified too often

Let’s assume that Foo.cs requires Bar.cs and Foo.cs is the one that is frequently modified. Knowing that we can safely move Bar.cs into the Standard Assets or Plugins directory, do you want to know what will happen then? From now on if you modify the Foo.cs script, the Bar.cs script won’t be recompiled!

Taking it to a real world scenario

How is this working in a real world? If you’re an Asset Store user (and I bet you are!) then your project may include assets such as NGUI, PlayMaker etc. The great things about these assets is that they come with a source code. The bad thing is that when you modify any source files in your project, all of these 3rd party source codes need to be recompiled too (like in our Foo Bar example!).
Then if you have these assets, the dependency is, in most cases, unidirectional. This means that your code is using imported assets, but imported assets are not using your code (again as in the example above).

Having it that way you’re safe to move these 3rd party assets into Standard Assets and Plugins directories? Right?! Wrong!!!

To make it work, the directory structure should be strictly kept as in the documentation. If you simply move your assets folders, most probably you will loose the access to the editor scripts inside them which will make them useless. You have to carefully reorganize the folder structure to make it work.

The human factor

When something is needed to be done carefully, the human factor is the one most likely to fail. Of course if you’re focused enough and you have enough time you can do it again and again, but who wants that?

Mad Compile Time Optimizer is reducing the human factor issue. It reorganizes the directory structure in a way that it will still work, but it cannot remove the human factor completely. You have to tell which assets can be moved (rarely modified assets) and identify the dependencies.

The reverting issue

So what if you’ve already moved your script files and you need to upgrade the asset? Mad Compile Time Optimizer gives you the ability to revert the operation so all files will be back where they originally were. By doing this, you will be able to upgrade your 3rd-party assets and optimize them again without breaking anything.