Unity Build Takes Too Long? Our Scripts-Only Build Took 5 Seconds Instead of 40 Minutes

Before and after comparison shots of a camera return fix in a slime making game. Six frames of the same screen sit side by side, with a dev build marker in the bottom right corner

If your only test build is a full build that bakes the maps and runs a launch check, verifying one bug fix takes 40 minutes. When only code had changed, a fast build that recompiles just the script DLL finished the same check in 5 seconds. Build the fast path for your test loop first, and run the full build once, at the end.

October 27: I Said the Same Thing Twice

It was the day I fixed a disqualification bug on the test PC. To check the fix I ran a build, but it was a full build that bakes 5 maps and then runs a launch check, so one run took 40 minutes.

At 4:51 PM I said, "Why does this take so long? Can't I just use dev mode instead of a build?" At 6:07 PM I said, "This really takes forever, please make it fast." Both times I was right.

After that I ran the fast build script, which compiles only the script DLL when only code has changed, and it finished in 5 seconds. That path had been there from the start, and I just wasn't using it.

What Sat Between 40 Minutes and 5 Seconds

Broken down, the full build does three things: bake the maps, build the player, and run it to check that it launches. Right before release you need all of it.

But all that changed this time was a few lines of disqualification logic. The maps were the same, and I still baked all 5 again. The only thing I wanted to know was "does the fixed code run correctly," and I waited 40 minutes for everything else to get there.

The fast build skips that. It compiles only the changed scripts into a DLL and reuses the results that were already baked. The same check took 5 seconds.

	Full build	Fast build
What it does	Bake 5 maps + build the player + launch check	Compile the changed script DLL
Time taken	About 40 min	About 5 sec
Use it when	Right before release, or when maps changed	Only code changed

How Many Fixes Fit in a Day?

Let me do the math. Even if you spend all 8 hours of the day on nothing but builds, a 40 minute build gets you 12 runs and a bit. That means the check, fix, check again cycle cannot happen more than 12 times a day. With a 5 second build, one cycle takes under a minute.

Bugs do not get caught in one try. You fix it, it is wrong, you fix it again, and it is wrong again. The number of cycles is the number of bugs you can catch in a day. What I lost that day was not 40 minutes. It was most of the cycles I could have run.

This number comes from the 40 minutes and 5 seconds written in my diary, plus an assumed 8 hour day. I did not keep a count of how many times I actually ran it in a day.

Four screenshots of the first order screen in a slime making game. Under the same hint text, a star shaped dough stretches and shrinks — I pull several of these check shots at a time to see a fix with my own eyes. With a 40 minute cycle, even this one shot costs 40 minutes.

The Cause Was the Order

When I first built the test loop, I did not set it up as "fast build first, full build later." There was only the full build. The fast build only appeared, along with the dev mode switch, after I got angry.

This is not about blame. It is about structure. When the test loop is slow, people check less. When they check less, they move on to the next task without knowing whether the fix worked. A slow loop does not stop at being slow. It makes you stop checking at all.

The Order I Set Up for Every New Test Target

Since that day, this is the order I set up the loop in for any new test target.

Every engine names it differently, but a similar path exists. In Unity, a development build has an option to rebuild only the scripts, and the editor has a Play Mode option that skips the domain reload. Either way the point is the same: build the path that redoes only what changed on day one.

Day one: build the path that runs a code only change in a few seconds (a fast build, or running straight in the editor)
Second: a dev mode switch that turns off things unrelated to the check, like map baking, long cutscenes, and ads
Last: run the full build only right before release and on days the maps changed
For each test loop, time it once and write down how many seconds the check takes

What I Have Not Fixed Yet

The fast build script and the dev mode switch exist now, but there is no rule or check that forces a new test target to get the fast build on day one. Right now it is a promise written on a single ticket. I will find out whether it really gets set up on day one when the next test target comes.

FAQ

How do I cut down a game build that takes too long?

Split the full build into what it actually does. If only code changed, you do not need to bake maps or process assets again. Make a separate fast build that compiles only the changed scripts, and run the full build only right before release. One check can drop from 40 minutes to 5 seconds.

Is there a way to rebuild only the scripts?

In Unity, a development build has an option to rebuild only the scripts, and it needs a player you built earlier. In the editor, a Play Mode option can also skip the domain reload. Names differ by engine, so search your engine's docs for "incremental build" or "scripts only build."

Can I just use the fast build all the time?

No. The fast build is for checking code, so it does not cover maps, assets, or running the real player. Right before release, and on days the maps changed, it is safer to run the full build once and compare the two.