How do I analyze what's driving the build size? (code)

Unity Engine
, , , , ,
1

I’m looking to understand what’s driving the binary and wasm size of our build.

Our WASM currently sits at about ~10MB compressed, but it has grown over time from version to version.

I’m looking for a way to understand what code files are included in the WASM and mobile builds (Android/iOS), but most build reporting tools focus on assets usage.

What’s the best way to go about mapping the code that contributes to the build size?

2

if you look in your editor.log file, you see a build breakdown, there are also assets that pull that out of there…

1 Like
3

So I can safely assume that everything in the build report went into the final build?
e.g., if I’ve got files from “some package X for platform Y” even though I’m building for platform Z, that means the packages is taking up space in my deployed build?

4

The build report in the log mostly helps pointing out what area most heavy assets come from. Typically the largest assets are textures, like 80% or more of the build size in most projects. Code will contribute almost nothing to the build size.

You can ignore the build report sizes as they are uncompressed.

First thing you should do is check the various Player Settings as they can largely affect build sizes. There are threads about minimizing WebGL build sizes. As to code I found it most effective to crank Code Stripping as high as possible though this can lead to crashes. Disable all “modules” (built-in packages) that you aren’t using as they can contribute several hundred Kb of compiled code for no reason, ie Vehicles, Wind, Cloth and such are good candidates for removal. Regular unused packages affect build size much less for some reason.

Just in case: Be sure to measure only release builds, not debug builds.

With Unity 6 you also get LTO (link time optimization) favoring either speed or size, although at the cost of an absurdly long build time.

The “Asset Hunters” do help in that sense because you may want to know how texture X came to be included in the build (ie find the material, then find the renderers using the material, then find the prefabs/scenes this is used in). Unity’s search tool can also help with that to some degree.

And you can use AssetDatabase.GetDependencies(..) in an editor script.

1 Like