WebAssembly export not compressing out of 5.6.0f1

Hello!

I’m VERY interested in messing around with the new experimental WebAssembly export, and I gave it a shot today with immediate success on one of our games. However, I noticed the build size of the exported version was quite a bit larger (570mb over 390mb) than our older WebGL build.

After further inspection, it looks like the gzip compression didn’t happen on the WebAssembly export, which obviously saves a ton of space. Will the WebAssembly export option be able to be gzip (or brotli) compressed in the near future, or am I missing something else here? Everything I’ve read says WebAssembly builds should be significantly smaller, so I’m hoping it’s just a bug or missing feature with the experimental version.

Thanks!
-Anthony

On further inspection, it looks like the size of the JS/Code files went down significantly when comparing uncompressed versions (23MB to 10MB), but the size of the .data files went up significantly when comparing uncompressed versions (438MB to 750MB).

I tried running both the WebGL build and the new wasm build in Firefox (with wasm enabled), and they both also had similar memory usage. The whole point of wasm is much less memory usage, right? Is this just an issue with the experimental build?

Any thoughts/insight here would be great!

  1. Wasm only touches code files. So only the code related files will go down in size.
  2. Wasm is planned to help with memory usage a bit and it is still experimental. What it does help with is startup time compared to just asm.js since it is precompiled. However the code you put into it from Unity is still the same.
  3. Your increase in data file size should not happen. From which version did you upgrade from? Are you using always included shaders? There was a change regarding shader variants. See Huge WebGL build size in 5.6 vs 5.4 - Unity Engine - Unity Discussions

If that isn’t it, please file a bug report with a repro project and ping the case number here. Thanks!

Thanks for the notes and clarification!

  1. got it.
  2. I realized the similar memory usage was probably because I had allocated the same amount for the Unity heap in both builds (d’oh). I can run the profiler on both to compare the difference. Since it looks like the wasm export also includes the regular WebGL asm files, is there a way to ensure I am indeed executing the wasm version of the code? Sorry if this is a dumb question, as I know wasm and js have to interact a lot - I’m using Firefox 52.0.1 where wasm is enabled by default.
  1. I rebuilt a regular WebGL export and the uncompressed file sizes were indeed identical for the .data file, so thanks for clearing that up. However, I did select gzip compression when exporting the WebGL build (no wasm) and it spit out uncompressed files. Should I submit this as a bug?

Alright, I tried connecting both a regular WebGL build and a wasm build to the profiler via dev builds, but it looks like the dev build didn’t build to wasm - just built a standard WebGL project. No wasm files were shown in the Build folder, so I wasn’t able to profile the differences in memory usage.

Bumping here to see if the “no gzip on WebGL builds” is a bug I should submit?

Hello again,

the build is compressed. We did however change the embedding and delivery of the webGL content in 5.6.
So most of the files end in .unityweb but will be compressed with whatever you selected.
If you compare it to a build without any compression you see the difference.

When you see a logerror line that it is using “binaryen” it means it is using wasm. Should probably make that a normal log, not an logerror.

Will check on wasm dev build shortly.

Wasm profiling seems to be broken in FF. It does work in Chrome Canary so try that and let me know if it works for you.

Bug for FF profiling will show up under Unity Issue Tracker - [WASM] profiler doesn't work with Firefox in a bit.