Search Issue Tracker

Fixed

Fixed in 2022.2.3f1, 2023.1.0a19

Votes

0

Found in

2022.2.0b8

2023.1.0a11

Issue ID

UUM-15615

Regression

Yes

WebGL build times have regressed

--

-

Many informal observations of the WebGL build time, in particular the final linker step now take longer than when we first moved to Emscripten 2 in Unity 2021.2

This is especially detrimental in our user's iteration time with development (debug) builds.

The change which likely caused this was the upgrade to Emscripten 3.1.8 in Unity 2022.2

Brendan found this issue, [https://github.com/emscripten-core/emscripten/issues/17019], that concluded compiling with "-sERROR_ON_WASM_CHANGES_AFTER_LINK -sWASM_BIGINT -O1" took linking time from 180 seconds to a couple seconds.

We set the linker options in Platforms/WebGL/WebGLPlayerBuildProgram/WebGLPlayerBuildProgram.cs
in the function SetupPlayerExecutable()
in particular the -O optimization flag is set on line 170
{code:java}
.WithOptLevel(!PlayerBuildConfig.Development && WebGlConfig.optimizeForSize ? "s" : "3")
{code}
We need to evaluate the linker flags used, particularly in our development builds to achieve the fastest link time possible, even at the expense of WASM size.

We should make sure that the release (non-development) builds remain with the optimal flags.

 

-- For anyone finding this Issue June 2023 or later --

Some clarifying information:
* The primary speed up referred to in this ticket 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 
* 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, the optimizations are for deployment or run time purposes. 
* Some slowness in recent versions is related to LLVM's LTO setting which provides additional optimization, however it comes at a time cost when building. For most situations using "Shorter Build Time" a viable release build.

If you see a significant increase in time taken while doing a _Development_ build or _Short Build Time_ optimization please let us know

When commenting on this ticket, please include additional data including versions being used, build options, and amount of time taken. Or please reach out on the forums.

  1. Resolution Note (fix version 2022.2.3f1):

    Verified the fix has landed to 2022.2.4f1 with Ubuntu 20.04

Comments (12)

  1. amateurd

    Feb 16, 2023 16:35

    It isn't fixed - still a problem in 2022.2.7f1

  2. DevDunk

    Jan 14, 2023 15:04

    What version will the fix be in? The issue says 2022.2.3, while the comment says 2022.2.4

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.