Building a project takes too long. On the previous version of the engine, the creation time was about 5 minutes maximum. In Unity 6 with the same settings, it takes from 30 to 40 minutes. What could be the reason?
5 Likes
Repeat builds too? The first build always takes 10-ish times longer.
Make sure you do a Development build since those are much faster.
I have tested different projects. Absolute new and clean. And repeated too. It’s always takes too long to make.
In the previous version of Unity. There is no problem at all
Hi!
What “Code Optimization” setting are you using for the build?
In Unity 6 there are two new settings “Disk Size with LTO” and “Runtime Speed with LTO” that use “Link Time Optimization” to create smaller or faster builds. But that comes at the cost of long build times. I would recommend them for release builds.
During development I can recommend to use the “Build Times” setting for faster builds.
Just as a “inspiration” for unity devs ^
Saw this on random twitch dev chat:
“the company I work for, we rewrote a part of the Unity compiler for web so we have like 5% compile time compared to default unity”
So definitely there are issues in current system…
(unity 6 feels slowest so far, at least cold build)
My build time also seems to be up a bit with Unity 6 vs Unity 2022. It’s taking around 13 minutes now. I could have sworn it was closer to 6-7 minutes with Unity 2022.
I came here for the same problem, it takes about 7 minutes for an “almost” empty project to build (WebGl)
Is this only for the first build with a fresh project or also on rebuilds?
What build options are you using: Code Optimization, Managed Stripping Level, IL2CPP Code Generation, Compression Format etc.?
Mine is running for over an hour. Code Optimisation : Shorter Build Time, Managed Stripping Level : Minimal, IL2CPP Code Generation : Faster (smaller) builds, Compression Formati : Brotli.
Yeah I can’t work under these conditions either. WebGL builds are taking so long I can’t get anything done
1 Like
Mine is running for over an hour. Code Optimisation : Shorter Build Time, Managed Stripping Level : Minimal, IL2CPP Code Generation : Faster (smaller) builds, Compression Formati : Brotli.
The settings here look good.
When we have dissected the previous root causes of slow build times, there is more identified cause for slow build times: does your project use precompiled native code plugins for the Web platform? (i.e. files in the project that would end in .a or .bc?)
It has been reported that if plugins that were compiled with an older edition of Unity (specifically, plugins before migration from LLVM bitcode to Wasm object code) are used in a project, then the Emscripten linker will trigger a “mixed-mode linking” path, where it will have to link together LLVM bitcode and Wasm object code. This process can take a long time.
So if you have .a or .bc files in your project, try to troubleshoot if removing those would speed up the build.
Other ways to speed up build times are to:
- Enable WebAssembly 2023 feature set. That can win a couple of minutes to a 5 minutes on the build, as it skips some legacy steps in the build process that were used to support old browsers, and
- Disable compression. Of course this should be done only for development time iteration. For final builds, using Brotli compression (and LTO) is recommended.
Build times that take up >30-40 minutes that have been reported to us have so far been due to accidental enabling of Link-Time Optimization (LTO), which are not good to be enabled in iteration builds. So doing Development builds or Release with Shorter Build Times will avoid use of LTO. LTO is only intended for Master builds (when game is uploaded as a final version).
If your project does not have any native plugins, i.e. no .a or .bc files in the project, and build times are still on the order of 30-40 minutes (and the project is not one of those massive AAA ones where it might be expected), then it would be useful to report that as a bug. It could be that we have a yet unknown root cause for slow build times that we need to resolve.
If your project does have native plugins, then asking for an updated version that is compiled with latest Wasm object files and LTO disabled, should avoid the slow build times with those plugins.
5 Likes
Thank you for this concise collection of advice, I found this thread via google when I was frustrated with my 30m+ webgl build times. I was on the verge of accepting that I couldn’t properly develop if it took that long to test the build itself. Development mode on, WebAssembly 2023 feature set on, no compression. My first build after that took about 6 minutes, the second build took less than 10 seconds. Finally, thank god. Most of my wait time was on the Link-Time thing, so I think it was just switching to development mode that did it. To be honest I should have probably been in the habit of setting that on anyway until an actual release, but with so many settings to change from their defaults in Unity it’s easy to miss the importance of some. Seeing how other users have had this horrible build time experience, maybe there should be some kind of window notifying the user that they’re building webgl for release which will dramatically increase the build time.
Something happened at v6000.0.23f1 onwards which made building with Runtime Speed optimisation infeasible. Started taking 45+ minutes for me. I just have to settle for shorter build time optimisation for the time being until someone fixes it, so I can make a proper release build
@jukka_j Thank you for some great info. I was not doing development builds as it warns you it increases build size/times. Counter intuitive if you are trying to shorten build times. Do i have override control to turn LTO off on a non development build?
While l am here I would like to complain about how much CPU is taken by a build. I really would like some control to throttle back the build at the expense of build times when I need to use my computer for other things during a build. Yes I know I can offload builds other ways but that is really besides the point.
Some kind of a slider on the build page where I could limit the amount of CPU taken would really be appreciated!!!
1 Like
Our project is also taking nearly an hour to build with “Runtime Speed” set when we want to do a release. Adding LTO on top of that adds several hours.
We are using
Code Opt: Runtime Speed
Managed Stripping Level: Low
IL2CPP Generation: Faster runtime
Compression Format: Brotli
Decompression Fallback: true
If we are doing a “low-level” deployment for testing we set Code Opt to “Shorter Build Time” and a clean build takes 10 minutes.
We don’t have any .a or .bc files in our project, but we do have the DOTween DLL. That is the only pre-compiled code. Everything else is source.
3 Likes
Any follow-ups to this? Concerned about the build times I’m seeing with Unity 6.1.6 but haven’t tried the optimization suggestions yet.
Recently I took on maintenance for a WebGL project that displays about 160 car billboard models. It uses the built in render pipeline, I can’t upgrade to URP because it uses some old custom shaders. When I tried to upgrade to Unity 6.1, the performance dropped dramatically compared to Unity 2022 ??
Oh, and one more thing, when I made a 2d game on WebGL for a client and uploaded it to itch.io, using unity 6.1, it completely stopped accepting input on mobile, I had to go back to Unity 2022.
Same issue here, but I’m planning to run clean builds on CI, so no previous artifacts, no cache.
Having a simple branch pull request check build take 40+ minutes is simply not acceptable by any means. This must be fixed for the next release, otherwise we can’t consider Unity a viable solution for what we’re creating.
1 Like