I’m testing the 4.18 Preview 2 with an HTML5 build and it seems that Chrome uses almost twice as much RAM as Firefox.
I made a new C++ project with the third person example and immediately packaged it for HTML5. Project settings changes: disable PAK, enable Tracing support, and enable compress during shipping. Packaged version is default development (so no compression).
I’m not sure if this is a bug, if I am doing something wrong, or if Epic can even do anything about it other than poke Google. I would expect the memory usages to be similar but not exactly the same. It’d be great if we could get Chrome’s usage down to near Firefox’s levels. The good news is that Firefox with wasm on 4.18 is about a third the memory usage of 4.17.2 with asm.js! Good job Epic! Huge improvement there!
Firefox 56.0 (64 bit). No installed extensions.
Chrome 61.0.3163.100 (Official build) (64 bit). Only Ad Block Pro extension installed.
When we were designing WebAssembly, the intent was exactly to improve the memory usage, which was not possible within the capabilities of asm.js. There are more memory optimizations coming in once multithreading lands, which has a prospect of removing the .data file from being kept around in memory. Other optimizations will also come in on the audio front, currently all audio needs to be uncompressed up front, but there is work going towards ensuring it is decoded in a streaming fashion when playing back.
It might be useful to check out Chrome’s memory tools to see if that can locate sources of the larger memory footprint:
I wonder if doing cross referencing there could locate Chrome’s memory issues here. In any case, it does sound like a Chrome issue, the code that runs on Firefox and Chrome is the same in both browsers, i.e. there are no browser-specific paths that the generated JS/Wasm would take that would explain such large memory differences. It is possible the that these issues are not issues exactly, but Chrome’s desire to favor speed over size on some optimizations, leading to larger memory usage as a result. (not sure, but that might be an outcome)
Thanks for replying and sharing your insights. I took a quick peek at Chrome’s heap profiler. I honestly have no idea how to interpret these results as it’s a bit beyond my expertise. The only thing that I notice though is that the majority of the memory usage is contained in two giant ArrayBuffers with suspiciously similar sizes. Chrome might be (unnecessarily?) duplicating some data.
The two large heaps sounds like expected. The largest one of these is the WebAssembly memory heap, which is initialized at the top of the generated .html file, the size of which is dictated by TOTAL_MEMORY in compilation. Note that this memory, even when shown in full in all profilers, is actually only reserved address space, and not used (committed) memory, until WebAssembly code actually touches memory pages inside the heap. To roughly gauge how much memory is needed for the heap, you can keep reducing the heap size in the main .html file until the page no longer loads. (also I think one needs to disable resizing).
You can also try evaluating “HEAPU32[DYNAMICTOP_PTR>>2]” in web browser page console to gauge how much of this heap is in use, though I can’t remember if that will work in Shipping builds.
The other big memory buffer is the file system, (.data file) which we are expecting to nuke away altogether when Wasm multithreading lands, because with multithreading, we can create an architectural solution where the individual files in the file system are loaded up on demand from IndexedDB.