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?
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.
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?
[quote=“sirrus, post:3, topic: 633276, username:sirrus”]
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.
[/quote]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.
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.
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?
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?
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?
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.
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.
The output directory comparison. Making sure it’s the asset files we think they are and all?
Sorry, just the release folder diffs with the gzipped build files?
Just a listing of each directory and size of each file.
Ideally something as magical as Scooter Software - Home of Beyond Compare showing loose files that are different or size differences as appropriate.
But even just a ls/dir recursive would be a start.
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:
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?
Also, any chance you could upload your project in a bug report or using some other means, so we could check it out?
Jonas,
Do you want both 5.3 and 5.4 uncompressed comparisons of output?
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.
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?
Jonas,
I submitted a bug report. Case #815795. Please keep me posted on what you find! Thanks.