Think this would probably be a simple fix, as this seems to be entirely in the loader.
Currently we are just checking to see if the 2018.1 loader will work out of the box with the 2017 asmjs, webasm files.
Also, would be kind of nice to just have access to the unminified loader code in cases where we need to tweak it. A bit hard to work with the minified versions.
Looks like the UnityLoader.js in 2018.1 âdoesâ seem to be a drop in replacement for the same file in 2017.3, at least for now. IndexedDB seems to shave a few seconds off of Firefox (we get about a 4-5 second load time) vs. 6-7.
Of course on Chrome, it seems that no matter what you do, WebAssembly is quite slow, and appreciably slower than straight ASM.JS (for us about 4-5 seconds slower).
For now weâre disabling webassembly on chrome with the following line in an unminified version of UnityLoader.js
hasWasm: âobjectâ == typeof WebAssembly && âfunctionâ == typeof WebAssembly.validate && âfunctionâ == typeof WebAssembly.compile && !/Google Inc/.test(navigator.vendor)
Our beta test site: https://watch-beta.3veo.com to try it out.
The indexedDB caching fix is already in 2017.3, the only thing missing is the wasm compiled module caching which is only in 2018.1 at the moment.
Generally, we aim at backwards compatibility so that you can use the latest loader with an old build. So, you should be able to use the 2017.3 loader with 5.6-2017.3 builds.
Just make a development build and you will get the unminified version 
Anything specific you need to tweak? (apart from hasWasm)
Is this on Windows or Mac?
You should be able to do the same in the html. You can modify UnityLoader.SystemInfo.hasWasm just before calling instantiate()
Mainly on Mac.
Our load times for 3veo on Mac Firefox is about 5-7 seconds. Chrome takes between 20-25 seconds - and its even slower if wasm is enabled (by about 3-5 seconds if I remember correctly). We disabled WASM on chrome for now because it was just too slow.
Youâre welcome to test yourself with https://watch.3veo.com (note: this version does have indexeddb loading deployed from 2018.1, and WASM disabled for chrome).
The times on PC are much better on Chrome. About 7 seconds on our high end PC, but Firefox on that same PC is only about 3 seconds (which gets close to regular web page load performance).
SureâŚ
Setting the heap memory size from the web page. In our app we play back clips of 3D content uploaded by end users, and not every piece of content requires the same amount of mem. Weâd like to be able to set the max heap from JS before loading. Each clip gets itâs own URL and itâs own template page, and we can place the clips required heap size on that page. I figure this is pretty specific to our use case, but it would be handy for us.
For right now, being able to disable/enable WASM. Not sure this is really useful long term if/when Google brings their load times in line with Firefox.
Itâs been convenient to share a common code base between web and mobile, but weâre biting the bullet now and replacing the browser UI of the app with React on the web to eliminate startup time.
Howevrer it was a surprise to see how much both indexeddb caching and Firefox 58âs new loader improved startup time though. 3-5 seconds on our PC was pretty astonishing.
do you mean by changing TOTAL_MEMORY? Be aware that this will only work with asm.js builds as the heap size is baked into the binary on WebAssembly.
On this topic, I should mention that we are experimenting with enabling heap growth on WebAssembly builds as of 2018.2
So, for your use-case, you will be able to make your builds with a small heap, letâs say 32MB. Then, on WebAssembly your build will just resize the heap at runtime if needed and on asm.js you will still be able to manually adjust TOTAL_MEMORY after making the build.
It might be possible this is Mac-only issue. It would be interesting to measure load times on Windows as well.
We are seeing the same with our WebGL games and Chrome (as well as Safari and Opera), tested on Mac and PC
Loading time with FireFox is around 6-7 seconds. Rest of the browsers have unacceptable loading times of 26-27 seconds.
On Chrome itself, of the 26 second loadingtime, 21 seconds are spend on:
âasynchronously preparing wasmâ
could you try Chrome Canary?
Unfortunately, same results there (Version 66.0.3332.0)
Hi Marco,
I stumbled upon this:
do you mean by changing TOTAL_MEMORY? Be aware that this will only work with asm.js builds as the heap size is baked into the binary on WebAssembly.
In KoGaMa we use this to ensure that as many games as possible can start. That is: If it is a small game we only allocate a small amount of memory and if it is a big game we allocate a huge chunk of memory. This is an important optimization for our product. Am I correct in assuming this is not at all possible in webassembly for Unity?
Hi Christian, I can confirm that is the case - I do something similar in a âbig dataâ streaming application. We allocate 2GB up front, but if we detect itâs a 32-bit browser we change that to 1GB. This doesnât work on WebAssembly builds due to the aforementioned limitation.
The 2018.2 dynamic growth feature sounds interesting although itâll be a while before we see the release of 2018.2 I am curious if the same memory constraints apply to this feature - i.e. a limit of 2GB? I realise this is a huge amount of memory in the web as-is but weâre curious if there is the potential for an application to request beyond that limit or if this is a hard-limit constraint of Emscripten or WebAssembly / JS.
Chrome canary cuts load time down to about 17-18 seconds⌠still way beyond what we would like, particulary compared to the 4-6 seconds Firefox takes to load.
Iâve manually set the loader to force webassembly in this version. Here is the performance trace. Note that because itâs running the profiler it is hitting about 24 seconds, but without profiling weâre seeing 18 seconds. This is also running from localhost, so there is no real bandwidth issue - this is all wasm loading.
I really suspect that there might be something wrong with our loader. As you see from the trace, Chrome is reporting that nothing is happening during the first 10 seconds or so. This could be because the wasm compiler infrastructure is simply not reporting to the profiler (doubtful but possible), or it could be that our loader/template is somehow hosed and we donât know it.
Previous versions of Chrome prior to the latest version showed work being done by the wasm system for the entire period up to the Unity startup code (which is at the end of the trace).
Iâd like to believe weâve just broken something in the loader by modifying the progress code maybe. In any case, Iâm going to try a straight âstockâ webgl template to see if that makes any difference.
In Chrome Canary I get similar results. What is different is that ASM.JS in Canary is slower. But WASM is not much faster.
Results:
Canary (localhost):
WASM Avg load time: 18s
ASM.JS Avg load time: 26s
Firefox (localhost):
WASM Avg load time: 2-3s
This does not seem to be specific to our app. The tanks demo has similar performance:
Firefox (tanks):
WASM - usually about 1s
Canary (tanks):
WASM - 8-9s
It seems to me that Chromeâs support for WASM is just several orders of magnitude slower than Firefox 58, and that Canary doesnât seem to improve the performance in any appreciable way.
This is bad news for us of course. For now I guess weâll need to inform our beta testers that the Chrome experience is substantially inferior to Firefox. Iâve pinged the Chrome guys before on support for for sRGB⌠itâs probably a good time to see if we can engage with them to find out precisely whatâs going on, as improving load performance is pretty important for us.
Thx for the answer. Marco: Is this something that could be fixed? I think we will not be able to use WebAssembly before Unity 2018.2 which I guess is late 2018?
Hi Christian,
Enabling heap growth is actually just an extra linked flag passed to emscripten. However, there is a problems if you want to allow heap growth and you canât wait for 2018.2: Unity builds both asm.js and wasm with the same settings (heap size and emscripten arguments). I have to say that even 2018.2 does not meet your requirements yet. Ideally, I think you would need a way to specify the initial size of the wasm heap so that:
How does that sound?
Interesting. Iâve heard of ALLOW_MEMORY_GROWTH before but dismissed it due to its performance impact on asm.js but in revisiting the documentation it has seemingly no impact on WebAssembly performance. I might give this a try!