Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Office Holiday

Epic Games' offices will be on holiday from June 22nd to July 7th. During this period support will be limited. Our offices will reopen on Monday, July 8th. 

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

Product Version: UE 4.11
more ▼

asked May 14 '16 at 06:31 PM in Packaging & Deployment

avatar image

1 1 2 3

avatar image RuneV May 18 '16 at 02:29 PM

Thanks for both replies. I noticed a "Samantha Sutton" marked the first reply as the answer, but although both answers are good, the second was most helpful to me.

Thanks again!

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

2 answers: sort voted first

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:

  • smaller files sizes

  • closer to metal run time binary data and instructions

  • and hopefully parallel processing pipelines

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.


more ▼

answered May 14 '16 at 11:03 PM

avatar image

nick.shin STAFF
476 5 4 9

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

There are two different major operations being performed while the text "Compiling" is spinning on the screen: JS page compilation, and UE4 engine startup.

The JS page compilation is the process where the JS code containing the engine and the game is added to the web page DOM, and the browser parses and compiles the JavaScript code that was added. In Firefox (and also Edge), you can see how much time this took by opening the page console (Menu -> Developer -> Web Console), and looking for the line

 "Successfully compiled asm.js code (total compilation time 6805ms; stored in cache)"

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

 "Successfully compiled asm.js code (loaded from cache in 643ms)"

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.

more ▼

answered May 15 '16 at 05:21 PM

avatar image

1.2k 15 4 17

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question