HTML5 compiling time
We are attempting to make a HTML5 build of one of our UE4 application. It is basically a 3D viewer with some animation attached to buttons.
Here is a test: http://vxl.no/test2/IsiFlo_Android.html 3 objects, and some keyframes added to one of the objects. 1 shader, using 3 instances to change diffuse colour.
The download time is normal depending on size, but the compiling time is 50 seconds in Chrome, 30 seconds in Firefox, and 10 seconds in Nightly. And this is constant no matter what we do, or which machine we use.
Nightly's compiling time is acceptable, but very few of our users will be using it. Any suggestions on how to speed up the compiling time to make it useful for an end user?
Best Regards R
asked May 14 '16 at 06:31 PM in Packaging & Deployment
compile times are the domain of the browsers. a lot of work is going into the browsers from the respective makers on making them faster.
that said, whenever i build and package for HTML5 -- i normally test them on nightly because of it's faster compile times.
sometime in the future, web assembly should also help:
since seeing UE3 running in the browsers, they've come a long way -- UE4 will consistently be improving to take advantage these new technologies as they come along.
answered May 14 '16 at 11:03 PM
There are two different major operations being performed while the text "Compiling" is spinning on the screen: JS page compilation, and UE4 engine startup.
at the top of the log. In Chrome, there is unfortunately no such information posted by the browser. In Firefox and Edge, this asm.js compilation step is done only once, and subsequent page loads will load the UE4 engine already compiled from browser's cache. So the 6805ms reported above occurs only on the first "cold" load time.
The second operation is that after the JS compilation, the UE4 engine starts up and loads all assets and shaders and the scene. This process starts up when the text "Running..." appears on the console window shown on the page. The time spent in this step is not logged, so you'll need to manually time it e.g. by instrumenting the HTML file.
Investigating which one of the two operations is the slow one can give a clue how to mitigate.
If the slowdown looks like it is the JS page compilation, it might be useful to profile the first time load vs subsequent loads. The difference in asm.js compile times in Firefox stable vs Nightly might be due to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1246132. The fix for that went in to Firefox 47 release channel, which is due to be out on 2016-06-07 (https://wiki.mozilla.org/RapidRelease/Calendar). Another difference might be if you were testing on 32-bit stable Firefox vs 64-bit Nightly Firefox?
Tried on 32-bit stable Firefox 46.0.1 vs 64-bit Firefox Nightly 49.0a1 (2016-05-15), where I do get 7 seconds as asm.js compile times on both browsers versions. UE4 engine startup takes about 5 seconds on both, which gives a 12 second first run cold load time, and about 5-6 seconds as the warm load time. However this is a very fast computer with 16 logical cores.
If the bulk of the time is consumed by the UE4 engine startup, it is likely to do with the number of assets in the package and the amount of startup code. One random guess is that it might be related to shader compilation, which is an operation that has been identified to be slow on some Windows systems. To verify this, one can use the browser performance profiler to test where the load time is spent. OS X is known to have more efficient shader compilation times, so also testing the startup times on an equal performance OS X system can be insightful. If the startup is being slowed down by shader compilation, there is this bug entry https://bugzilla.mozilla.org/show_bug.cgi?id=918941 which discusses mitigating the shader compilation performance issue for warm loads in Firefox. Not sure how this relates to Chrome, although Firefox and Chrome reuse the same architecture for shader compilation on Windows (browser -> ANGLE -> Microsoft HLSL compiler).
In Firefox, WebAssembly will greatly improve JS compilation times for cold loads, although for warm loads, there is very little change. Warm loads with asm.js in Firefox should be very fast already, and on second load you should see something like
In Chrome unfortunately load times are pretty bad, and it doesn't implement any kind of caching of compiled code that I'm aware. With WebAssembly they will hopefully get closer to Firefox and Edge performance.
answered May 15 '16 at 05:21 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here