A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Separate names with a comma.
Discussion in 'Editor & General Support' started by doodler345, Jul 28, 2022.
Damn i was eager to upload a build now that o got my server running but ran into this
Something is "cold" if it's being done from scratch. A cold start of the power grid would happen if there was a complete blackout, for example.
So, a cold build happens if you've completely cleared all of Unity's temporary files -- it has to do everything from scratch, which takes longer.
The opposite is "warm". Unity has already done a bunch of the work; it just needs to work on things that have changed since the last build.
CORRECTION 2022.2.2.3f1 has fixed the issue !!!!
I'm getting this issue in 2022.2.3f1
WebGL builds as of 2022.2.3f1 now take about 7 minutes for me (vs. 20 minutes previously). If I haven't changed any code it's about 1 minute. Windows 10, Ryzen 7 4800H, SSD, 16GB RAM.
Edit: 4f1 seems even faster, taking just 3-4 mins after code changes.. *swoons* - at least for me it's the fastest it's ever been, for as long as I've been using the engine (i.e. 2019.x).
After switching to 2022.2.4f1 from 2022.2.0b16 my build time is now 59 minutes (up from 32 minutes).
Are you optimizing for runtime speed or build size?
The quick answer is that I thought it was being set for runtime speed, but it's actually been for build size/shorter time. These are what is displayed:
In my automated build process (i.e. not using the dialog), I set to the above Master and Faster runtime for WebGL release builds shown above by doing this,
However, in Build Settings dialog, the dropdown there says "shorter build time".
So I manually changed it to "Runtime Speed" and then ran the automated process again (with there being code changes since my previous build) and it took 32 minutes. Made more code changes and built again, still on "runtime speed", and again it took about 32 minutes. Then I changed it to "Shorter Build Time" again, made more code changes, and it took less than 3 minutes (I'm currently using 4f1).
I came to realize that while my script is setting Player Settings->Other->Configuration properties as expected, that dropdown shown above doesn't change as well.. and I can't figure out how to do it procedurally, the 3rd "Disk Size" option isn't displayed for UnityEditor.Build.Il2CppCodeGeneration enum code completion, so there must be another enum (?) and something else that needs to be done to handle this dropdown (..do you have any idea ?)
Finally, as I'm not sure how long this has been the case (that dropdown overriding SetIl2CppCodeGeneration) and don't have 2f1 or earlier installed anymore, I don't know if a) I've been on "shorter build time" for a while without noticing and that path just got much faster.. and performance of builds made with it is just reasonably comparable to "runtime speed", or b) it's been compiling for "runtime speed" pre-3f1 and somehow doesn't now without also setting that dropdown in 3f1+.. in which case that path is now slower, confirming what you've said.
Still isn't fixed in Unity 2022.2.4f1
If you have a project which is in both versions with and without the bug, make a big report and attatch both projects
Looks like 2022.2.5 resolved both WebGL and IL2CPP build issues. Build times are back to normal.
Actually I have the same problem with both 2022.2.4 and 2022.2.5 . My build is currently taking over 40 minutes. Code optimization set to Runtime Speed
Still broken in 2022.2.7f1
Can confirm it still doesn't work in 2022.2.6f1. Build reaching almost 1:30 hours and my PC was slowing down really bad. Reverting to 2022.1.22f1 for now
I don't think that addresses the issue we are facing, its a different bug.
still going in 2022.2.7
what's so hard about fixing this? can somebody shed some light? we're going back and forth, fixing, regressing, fixing and regressing again. sounds like someone does a really bad job in containing this issue
For my project, if i want to build WebGL:
2022.1.* takes about 10min to build WebGL version.
2022.2.0b16 takes more than 40min but I don't know how long because I canceled.
2022.2.7f1c1 takes 15min. I think I can accept it.
This is absolutely horrible! Latest 2023.1 beta. Brand new project with one UIToolkit document. Still going after ~10min. 2022.1 takes about 3min. It is not fixed at all.
Running on a beta, so quite an instable land... but, 2023.1.0b5 also failing, it is a quite small stuff and it goes for 20:57 seconds as im typing here.
2022.2.9 and still the same thing
Unity version 2022.2.9 still has the same problem.
Our project compiled with Unity 2020.3.34 takes 15 minutes to be created.
With Unity 2022.2.9 we need more than 30 minutes.
Code optimization is set to Runtime Speed in both cases.
Any idea when this will be fixed?
If you have a reproduction project in the latest version, make a bug report and maybe link this thread. The issues I've seen linked have been fixed, so won't be looked at
Still broken in Unity 2022.2.11 for me - keep having to revert to 2021.1.24.
1. As said, the original issue is marked as fixed, make a bug report
2. 2021.3 also is a good upgrade instead of going all the way to 2021.1
The issue is still happening in the latest 2023.1 beta. All you have to do is make an empty project in 2021 vs 2023 and see the build time. Its ~4 vs ~15.
Also having this issue still in 2022.2.12. I did not have it in 2021. WebGL builds are taking significant longer, making it quite a pain to get updates out. Build times previously took around 3-6 minutes, now are taking over 30 minutes. Same as stated, the process takes extremely long on "Linking build.js (wasm)". Any word on this issue?
Also, has an official bug report been filed on this yet?
Not sure what the process is - it clearly isn't fixed at all so I don't see the point of it being submitted again. They'll just mark it already fixed!
It does not happen at all on 2021.1.24. It eventually happens on all versions since. Clearing Player settings and deleting the Library folder stops it happening but it always comes back.
I am stuck on 2021.1.24 until Unity do something with it.
I am on 2022.2.12 and encountered the issue. For me I just updated the project from an older version. I needed to delete the whole Library folder, the old build folder, and then make sure in my build settings, code optimization is set to "shorter build time".
Since the build is stuck at "Linking build js.wasm", I suspect that the issue is with LTO (link time optimization) taking too long.
Indeed deleting the Library folder and the Temp folder does stop the problem happening, but only for a time on mine before it comes back. It would be more understandable with old projects but here it happens on a brand new project created in Unity 2022.2.11 containing one scene, one GameObject and one script.
Perhaps we could ask for a feature to be added to Unity so it will delete and rebuild the LIbrary folder before each build?
I filed a bug report and it looks like the bug has already been reported. It didn't have any votes though. If everyone could vote on this so we could get it fixed ASAP, that'd be great! Here is the bug report: https://issuetracker.unity3d.com/issues/build-times-are-very-long-when-building-for-webgl
Some clarifying information:
The primary speed up referred to in https://issuetracker.unity3d.com/issues/webgl-build-times-have-regressed is related to Development builds. As an example an empty scene targeting WebGL development build in 2022.2.2f1 -> 437 seconds compared to same project built in 2022.2.8f1 -> 156 seconds
note that all fixes are not backported into all versions
If you are iterating locally and want to test a build quickly, use development builds when you can.
In newer builds of the Editor an option Shorter Build Time was added and could be used for quick iteration with QA
Runtime Speed or Disk Size release builds are still going to take significantly longer to build. Although best efforts are made to not negatively impact build times and improve them when possible.
I attempted builds locally using the project attached in https://issuetracker.unity3d.com/issues/build-times-are-very-long-when-building-for-webgl
2022.2.8f1 -> build time -> 282 seconds
2022.2.8f1 -> runtime speed -> 848 seconds
2023.2.07a -> build time -> 316 seconds
It sounds like a lot of folks are chiming in on this, so I want to make sure there isn't a regression or bug here - it will be really helpful if people can do the following when indicating this is impacting them:
Provide the following information [Editor Version, Build Optimization, Time taken to complete the build, Host Operating System (if mac m1 or intel)] for a version in which it is "fast" and a version in which it is "slow" - without including the Optimization or Build Type it isn't possible to compare it apples to apples.
Confirm which optimization setting is being used when building
public class BuildTimer : IPreprocessBuildWithReport
public int callbackOrder => 1;
public void OnPreprocessBuild(BuildReport report)
Offhand, I'll provide some quick info I have.
Operating system: Windows 10 Home. OS build: 19045.2728
Processor: Intel i7-7700
Unity Editor version: 2022.2.12
Code optimization setting: Runtime speed
Time taken to complete: Roughly 40 minutes. Was previously in the ballpark of 6 minutes in Unity 2021.
As someone mentioned earlier in this thread, the version of emscripten changed which resulted in overall slower times including development builds, which was addressed.
I will see about getting some numbers internally for the different times taken specifically for Runtime Speed. Although we never want build times to become a pain point, when developing it is recommended to use either Development Builds or the Build Time optimization. Is a development build still roughly in the 6 minute ballpark for you in 2022.2.12?
Ok just tested! Development build does NOT take the inflated amount of time and seems to complete around 5-6 minutes like it should.
I usually don't need to play test on WebGL much. I push updates for my game around once every week or two, so come Friday, having to wait 40 minutes for the final product is a bit rough. =/
If you need more info, just let me know.
You should see a significant increase in build time when performing incremental builds, a build that involves a limited number of files being changed. Can you confirm if new builds with the same settings are significantly faster or if they still take 40 minutes?
Ok, yea I recall incremental builds being a faster in 2021. I just tested in 2022, first build took around 40 minutes, and second build (without any changes) only took like 4 seconds.
I'm trying to understand here, with the new emscripten version does this mean that this is how it's gonna be from now on, or are there efforts being put to fix the issue?
That's a bad test. Do a 'small' change in code (comment out a line).
Overall, I find this regression very frustrating. We don't use development builds because we test on real environments, either VMs or Cloud. This is WebGL, by definition we deploy on Web and thus on Web Apps. So we test with compression on, with release flags on, with release build settings (smallest build size possible).
In short we don't create development builds or different-from-release-settings-builds as our experience has shown that we can't trust the platform to be stable enough to make sure new issues aren't created by changing build settings.
Just to name a few issues we had in the past;
- Managing core engine call order / executing time regressions (that have changed between Unity versions) with compression vs without compression
- Errors/differences when stack trace is enabled / disabled
- Errors/differences when various code-optimization settings are used
- Errors/differences when in non-development builds
- Errors/differences when using different IL2CPP code generation settings
Are you working on improving the iteration time of non-development builds or is the build-time optimization flag our only hope?
Thank you for the detailed reply and my apologies for the delay in a response.
In positive news your feedback helped drive an internal conversation around the exposed build options, the perception of the community and how we can improve the workflow for everyone. Although we always want to strive to improve workflows for users, some aspects of build time will remain out of our control.
Some of the slowness experienced is related to LLVM's LTO setting although it provides additional optimization it comes at a time cost. We are actively working through exposing LTO as a separate option so it will be up to you to decide if the additional optimization or reduced build time is preferred.
Reference for understanding the following flags: https://emscripten.org/docs/tools_reference/emcc.html#
Mapping Unity WebGL build optimization to the emcc flags used:
Development -> -O1
Optimize For Size -> -Os
Optimize For Speed -> -O3
Optimize For Build Time -> -O2
One final thing, although I understand your hesitation to use different build types for your workflow, I will again suggest development builds for local iteration or try out Optimize For Build Time and compare the final artifact for your project and if the size isn't significantly different maybe you can use that option instead. The pain you described in the differences between options should *not* be the case. Please help us and other users by documenting and reporting to the best of your ability when you discover these issues.
Appreciate the reply.
Another consideration to take into account is that compared to other platforms, using WebGL development builds require a dual-integration in web apps due to the file extensions being changed when there's no compression.
I, like many, don't use the WebGL Templates because we integrate in existing frameworks (in our case, NextJS/React). Maintaining that dual integration within the pipeline of environments from DEV to PROD hasn't proven to be worth it yet.
Having a seamless WebGL-supported DevOps that manages Dev Builds, Release Builds in multi-ENVs requires much more automatization & infrastructure than other platforms - something that discourages users to play with build settings once they found one that works for them.
We do when we can, but this is the result of our experience over the course of almost a decade of using WebGL (Unity5+) and Unity in general (started with NPAPI in 2010).
From our perspective, we are lowering risks, maintenance costs & dependencies by keeping our build flags stable - that said, we will revisit Optimize For Build Time -> -O2 flag as our new default.
Some Stats --- Ryzen 7950X, DDR5 6000 - 64GB, Samsung 980 Pro 1TB.
Current project - Unity 2022.2.9;
- Optimize For Build Time: 7.45MB player size, clean build time of 85 sec followed by an incremental (1 line change) build time of 66 sec.
- Optimize For Build Size: 6.55MB player size, clean build time of 153 sec followed by an incremental (1 line change) build time of 136 sec
Looking at future trends - Unity 2023.2.0a9;
- Optimize For Build Time: 7.55MB player size, clean build time of 95 sec followed by an incremental (1 line change) build time of 70 sec.
- Optimize For Build Size: 6.89MB player size, clean build time of 173 sec followed by an incremental (1 line change) build time of 152 sec
Looking at future trends - Unity 2023.2.0a10 + BigInt & WebAssembly.Table;
- Optimize For Build Time: 7.55MB player size, clean build time of 91 sec followed by an incremental (1 line change) build time of 67 sec.
- Optimize For Build Size: 6.92MB player size, clean build time of 168 sec followed by an incremental (1 line change) build time of 149 sec
Note: There was supposed to be a build-size improvement. Our tests show otherwise.
I know it's an alpha, but unless there's a regression, it doesn't bode well for anyone expecting quicker build times OR lower build sizes...
Edit: Updated with Unity 2023.2.0a10 + BigInt & WebAssembly.Table
Is increased resource utilization during the the build process something Unity can do or is that a toolchain limitation?
It hurts seeing both IO/CPU utilization never exceed 10% for 90% of the build time...
Seems to be working better for me with 2022.2.15. Incremental builds are good, sometimes need to trigger a clean build when it misses changes (rare). Build times down to about 5 minutes which is pretty good.
Are you sure? I just tested it in 2022.2.16 and it is still the SAME!
So far, yes. The only things I changed is I have Code Optimization set to "Shorter Build Time" and I brielfy switched to gzip compression and then back to Brotli. It still shows "Linking build.js" but only for a few minutes (this is where it used to get stuck forever). Longest build time when set to "clean build" has been about 5 minutes. Sorry I have no idea what changed in Unity to fix it.
Hey, I just tested it with "Shorter Build Time" setting and it does seem to work. It took like 30 mins in the first build and now almost instantly in the subsequent builds. Still takes like 10 mins if there are small changes in the code, but there is some improvement. But "Faster runtime" is an ideal setting, and till now I have not been able to get a build with that setting because it seems to take forever(1hr+) and I feel like it could be stuck in some sort of loop. If I get time I will try running some tests and see what I can find.
Brilliant, seems like at least you and I are having the same behaviour. Good luck!
2022.2.9 has problem, 2022.2.16 no have problem good.
linking build.js is taking 17 minutes for me on 2022.2.18 Code Optimization: Runtime Speed
It used to take about 5 minutes in 2022.1 and before.
In 2022.2.18 if I change it to Code Optimization: Shorter Build Time, it takes 6 minutes or so.
Problem still alive in 2022.2.19
Also still having this issue. Any word from the Unity team? It's making pushing updates for my game out quite a bit more cumbersome. Still present in 2022.2.19.