Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  3. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

WebGL build size

Discussion in '5.4 Beta' started by sirrus, Jul 15, 2016.

  1. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Thought I'd give the 5.4 RC a go.

    Well, the data file for our WebGL release build went from 2.3MB (in 5.3.5f1) to 14.4MB (5.4.0rc1)!!

    Someone might want to take a look at that?
     
  2. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,660
    You're going to have to send us the project (via a bug report). Our tests for 'basic' WebGL application sizes have not increased, so it's going to be something specific that you're using that is responsible for the change.
     
  3. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    I certainly dont consider our project complex (as opposed to 'basic'). We only use 3 very small plugins and most everything else is packaged into assetbundles.

    Rather than supply the entire project, can I provide build reports instead? Or are they of no use?
     
  4. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,660
    Well, it may still be one of those 3 plugins. You could try building projects in 5.3 and 5.4 that have just one of them, then two of them, etc, to see if adding one particular plugin causes the size to explode.

    We really need a project (so we can run it through the build process ourselves). If you're able to successfully narrow it down to one of the three plugins, a project with one of the plugins in would be enough, but if you're not then we'll need the whole project.
     
    Last edited: Jul 18, 2016
  5. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Well, as expected, removal of the same plugins we've been using since 4.6 did not change the build size bloat.

    Is there a new setting in 5.4 that might cause this? We have tried disabling "Strip Engine Code" and "Data Caching" from our publishing settings with no different outcome.

    This is a *release candidate* so it's a bit frustrating to have to go through this process for something this (seemingly) massive this late in the cycle.

    Is there something else I should look for that "we're using" that might cause this? I understand the need for reviewing an entire project for QA but it is not always a simple task for all devs (policies/protocols and all that).

    Thanks.
     
  6. Alex-Lian

    Alex-Lian

    Guest

    So, we have our automated tests with sample projects to test WebGL builds, and that didn't trigger any failures.

    Thus, we know it's obviously something we're not testing by default, and without seeing your project, it's hard to guess. We might be overlooking something that yes, we possibly modified in 5.4, and happens not to be in our test projects for size testing. However, combing through 5.4 changes guessing as to what it is isn't going to guarantee fixes that address your case.

    Have you compared build reports of your own between 5.3.5f1 and 5.4.0f1, there's nothing showing there?
     
  7. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Our tests only cover code size, so that would not dispute this. Plugins and "Strip Engine Code" settings should also only really affect code size. Is this a development or release build? If development, what is the difference on a release build like?
     
  8. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Below are the size statistics from our build reports in 5.3 and 5.4, respectively. This is using the "Build Report Tool" asset available via the asset store and is for release builds (the only difference being the Unity version).

    The only noticeable difference I see is the Scene size ("Levels") being slightly higher in 5.4 by ~800kb. NOTE: I cutoff the script DLL list in the screenshots but they are the same in both builds.

    Anything I'm overlooking?
     

    Attached Files:

  9. Alex-Lian

    Alex-Lian

    Guest

    Hm, one more comparison - on disk, a directory compare?

    Build report seems like the contents seem fairly close, whereas it looks like final results so either compression or something else is laying around. No idea how the build report tool there calculates any of it's pieces.
     
  10. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    A project directory comparison?

    I can run a comparison for development builds. If they are similar in size, would that point pretty strongly to a compression issue?

    I believe this build report tool just parses the Editor log and spits out the info in more readable formats.
     
  11. Alex-Lian

    Alex-Lian

    Guest

    The output directory comparison. Making sure it's the asset files we think they are and all?
     
  12. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Sorry, just the release folder diffs with the gzipped build files?
     
  13. Alex-Lian

    Alex-Lian

    Guest

  14. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    OK, hope this is magical enough :). It's the WebGL output folder but I feel like you may be requesting the Assets folder of the project?

    Anyway, 5.3 on left, 5.4 on right:
     

    Attached Files:

  15. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    I think I have an idea of what may be going on here. We apply lz4 compression before gzip compression, to keep assets small in memory, and not just in downloads. 5.3 should have also done it, but it turns out that this broke in recent 5.3 releases. Now, this produces bigger data then only gzip compression, but the memory improvement is typically worth it. In typical cases, results would be 5-10% bigger. And, that is also the difference I can reproduce building simple projects with 5.3 and 5.4. So, your size increase seems odd and unexpected, but I'd still like to figure out if it might be caused by this. Maybe your assets are formed in some way where this double compression encodes them really inefficiently? Can you try making a build from an editor script and pass BuildPlayerOptions. Uncompressed?
     
  16. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Also, any chance you could upload your project in a bug report or using some other means, so we could check it out?
     
  17. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Jonas,

    Do you want both 5.3 and 5.4 uncompressed comparisons of output?
     
  18. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Using BuildOptions.UncompressedAssetBundle didn't really change the output file sizes much at all. It decreased the data gzip file by about 100k in both 5.3 and 5.4.

    FWIW, by design, we don't have many assets in the actual build. A few required UI textures for loading screens/error handling and some placeholders for components that otherwise get stripped out but that's about it; everything else is downloaded at runtime via assetbundle.
     
  19. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Ok, so then, maybe my initial thought about this was wrong. So I'm pretty much clueless. Could we get a project folder to look at, please?
     
  20. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Jonas,

    I submitted a bug report. Case #815795. Please keep me posted on what you find! Thanks.
     
  21. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Sorry to bump, just wondering if anyone has had a chance to look at this? It's preventing us from considering a 5.4 upgrade.
     
  22. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
  23. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    We don't know what is causing it yet. Just sharing some findings so far:
    -The problem seems to be project specific (cannot repro it on random test projects)
    -The problem does not seem to be WebGL specific (Win standalone builds are also much bigger)
     
  24. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    So, it seems what is going on here is:

    -You added the Standard shader to "Always included Shaders"
    -Unity 5.4 added more possible permutations to the standard shader. Now, all of these get built and included in the build. This increases Build sizes and Build times.
    -Instead, this should be used https://docs.unity3d.com/ScriptReference/ShaderVariantCollection.html
    -5.4f2 should add a warning about this case.
     
  25. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Jonas,

    Thanks. We have always run into problems using the Shader Variant Collection which is why we had to include the Standard in the build (it was the only option that seemed to work with all our assets in WebGL). We'll have to revisit this process, I guess.

    Thanks for the quick evaluation of the issue!
     
  26. Alex-Lian

    Alex-Lian

    Guest

    A bug for the Shader Variant Collection issue would be welcome if you do run into it again.