Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Question WebGL build "linking build.js (wasm)" takes forever

Discussion in 'Editor & General Support' started by doodler345, Jul 28, 2022.

  1. AaG_xd

    AaG_xd

    Joined:
    Jun 13, 2016
    Posts:
    2
    Damn i was eager to upload a build now that o got my server running but ran into this :(
     
  2. chemicalcrux

    chemicalcrux

    Joined:
    Mar 16, 2017
    Posts:
    720
    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.
     
  3. francineW

    francineW

    Joined:
    Sep 15, 2022
    Posts:
    10
    CORRECTION 2022.2.2.3f1 has fixed the issue !!!!
     
    yukunlinykl likes this.
  4. MobeusQuincy

    MobeusQuincy

    Joined:
    May 10, 2022
    Posts:
    1
    I'm getting this issue in 2022.2.3f1
     
    Skyblade likes this.
  5. adamgolden

    adamgolden

    Joined:
    Jun 17, 2019
    Posts:
    1,549
    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).
     
    Last edited: Jan 28, 2023
    yukunlinykl likes this.
  6. Davey111111

    Davey111111

    Joined:
    Dec 30, 2020
    Posts:
    2
    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?
     
    Last edited: Jan 28, 2023
  7. adamgolden

    adamgolden

    Joined:
    Jun 17, 2019
    Posts:
    1,549
    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:
    a.png

    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,
    Code (CSharp):
    1. PlayerSettings.SetScriptingBackend(EditorUserBuildSettings.selectedBuildTargetGroup, ScriptingImplementation.IL2CPP);
    2. PlayerSettings.SetIl2CppCompilerConfiguration(EditorUserBuildSettings.selectedBuildTargetGroup, Il2CppCompilerConfiguration.Master);
    3. PlayerSettings.SetIl2CppCodeGeneration(UnityEditor.Build.NamedBuildTarget.WebGL, UnityEditor.Build.Il2CppCodeGeneration.OptimizeSpeed);
    4.  
    However, in Build Settings dialog, the dropdown there says "shorter build time".
    b.png

    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.
     
  8. smabverse

    smabverse

    Joined:
    Dec 26, 2022
    Posts:
    1
    Still isn't fixed in Unity 2022.2.4f1

    upload_2023-2-1_0-6-59.png
     
  9. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    4,971
    If you have a project which is in both versions with and without the bug, make a big report and attatch both projects
     
  10. Destruxion

    Destruxion

    Joined:
    Jun 5, 2019
    Posts:
    37
    Skyblade likes this.
  11. unity_1D4395716672639296FF

    unity_1D4395716672639296FF

    Joined:
    Sep 24, 2021
    Posts:
    2
    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
     
  12. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    97
    Still broken in 2022.2.7f1
     
  13. arjuniscool0204

    arjuniscool0204

    Joined:
    May 16, 2017
    Posts:
    14
    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 :(
     
  14. arjuniscool0204

    arjuniscool0204

    Joined:
    May 16, 2017
    Posts:
    14
  15. FranktheGame

    FranktheGame

    Joined:
    May 9, 2018
    Posts:
    6
    still going in 2022.2.7

     
    Skyblade likes this.
  16. xucian

    xucian

    Joined:
    Mar 7, 2016
    Posts:
    836
    confirmed 2022.2.8f1

    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
     
  17. yukunlinykl

    yukunlinykl

    Joined:
    Dec 17, 2021
    Posts:
    21
    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.
     
    xucian likes this.
  18. TomTheMan59

    TomTheMan59

    Joined:
    Mar 8, 2021
    Posts:
    354
    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.
     
    EnableEd likes this.
  19. Arcanebits

    Arcanebits

    Joined:
    Dec 18, 2013
    Posts:
    108
    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.
     
  20. AaG_xd

    AaG_xd

    Joined:
    Jun 13, 2016
    Posts:
    2
    2022.2.9 and still the same thing :(
     
  21. jsr2k1

    jsr2k1

    Joined:
    Aug 11, 2010
    Posts:
    118
    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?
     
  22. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    4,971
    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
     
  23. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    97
    Still broken in Unity 2022.2.11 for me - keep having to revert to 2021.1.24.
     
  24. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    4,971
    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
     
    amateurd likes this.
  25. TomTheMan59

    TomTheMan59

    Joined:
    Mar 8, 2021
    Posts:
    354
    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.
     
  26. therobby3

    therobby3

    Joined:
    Jan 30, 2019
    Posts:
    131
    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?
     
    Last edited: Mar 27, 2023
    MousePods and PaulRdy like this.
  27. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    97
    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.
     
    Last edited: Mar 27, 2023
  28. ph3rin

    ph3rin

    Joined:
    Jul 22, 2018
    Posts:
    3
    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".
    upload_2023-3-26_23-50-24.png

    Since the build is stuck at "Linking build js.wasm", I suspect that the issue is with LTO (link time optimization) taking too long.
     
    tantx and amateurd like this.
  29. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    97
    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?
     
  30. therobby3

    therobby3

    Joined:
    Jan 30, 2019
    Posts:
    131
    amateurd likes this.
  31. JustBeanUnity

    JustBeanUnity

    Unity Technologies

    Joined:
    May 28, 2020
    Posts:
    7
    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
      Code (CSharp):
      1. using UnityEditor;
      2. using UnityEditor.Build;
      3. using UnityEditor.Build.Reporting;
      4. using UnityEngine;
      5.  
      6. public class BuildTimer : IPreprocessBuildWithReport
      7. {
      8.     public int callbackOrder => 1;
      9.  
      10.     public void OnPreprocessBuild(BuildReport report)
      11.     {
      12.         Debug.Log(EditorUserBuildSettings.GetPlatformSettings(BuildPipeline.GetBuildTargetName(BuildTarget.WebGL), "CodeOptimization"));
      13.     }
      14. }
     
    CodeSmile and BlackSpider like this.
  32. therobby3

    therobby3

    Joined:
    Jan 30, 2019
    Posts:
    131
    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.
     
    Skyblade likes this.
  33. JustBeanUnity

    JustBeanUnity

    Unity Technologies

    Joined:
    May 28, 2020
    Posts:
    7
    Thank you.

    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?
     
    BlackSpider likes this.
  34. therobby3

    therobby3

    Joined:
    Jan 30, 2019
    Posts:
    131
    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.
     
  35. JustBeanUnity

    JustBeanUnity

    Unity Technologies

    Joined:
    May 28, 2020
    Posts:
    7
    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?
     
  36. therobby3

    therobby3

    Joined:
    Jan 30, 2019
    Posts:
    131
    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.
     
  37. arjuniscool0204

    arjuniscool0204

    Joined:
    May 16, 2017
    Posts:
    14

    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?
     
  38. KamilCSPS

    KamilCSPS

    Joined:
    May 21, 2020
    Posts:
    444
    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?
     
    tantx, EnableEd, BlackSpider and 4 others like this.
  39. JustBeanUnity

    JustBeanUnity

    Unity Technologies

    Joined:
    May 28, 2020
    Posts:
    7
    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.

    https://emscripten.org/docs/optimizing/Optimizing-Code.html#lto

    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.
     
    arjuniscool0204 and KamilCSPS like this.
  40. KamilCSPS

    KamilCSPS

    Joined:
    May 21, 2020
    Posts:
    444
    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
     
    Last edited: Apr 14, 2023
  41. KamilCSPS

    KamilCSPS

    Joined:
    May 21, 2020
    Posts:
    444
    @JustBeanUnity;
    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...
     
  42. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    97
    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.
     
  43. arjuniscool0204

    arjuniscool0204

    Joined:
    May 16, 2017
    Posts:
    14
    Are you sure? I just tested it in 2022.2.16 and it is still the SAME!
     
  44. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    97
    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.
     
  45. arjuniscool0204

    arjuniscool0204

    Joined:
    May 16, 2017
    Posts:
    14
    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.
     
    tantx likes this.
  46. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    97
    Brilliant, seems like at least you and I are having the same behaviour. Good luck!
     
    arjuniscool0204 likes this.
  47. programmer119

    programmer119

    Joined:
    Sep 27, 2021
    Posts:
    94
    2022.2.9 has problem, 2022.2.16 no have problem good.
     
  48. Scott-Steffes

    Scott-Steffes

    Joined:
    Dec 31, 2013
    Posts:
    59
    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.
     
  49. hafu985

    hafu985

    Joined:
    Aug 27, 2021
    Posts:
    5
    Problem still alive in 2022.2.19
     
  50. therobby3

    therobby3

    Joined:
    Jan 30, 2019
    Posts:
    131
    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.