Skip to content

Chrome Memory Issues

Alon Zakai edited this page Oct 22, 2015 · 11 revisions

There are a bunch of known memory issues with running in Chrome,

See also these general observations:

Possible mitigations

  • Make sure to fully optimize the build (-Oz, -O3 or -Os, for example); unoptimized or less-optimized builds take a lot more effort to run.
  • Use the lowest possible TOTAL_MEMORY. In particular 32-bit Chrome seems to have a hard limit at 1GB, so if you can use just a little less like 950MB, that can work.
  • Use --separate-asm, to split out compilation from starting to run the code, maximizing the chance that the browser can reclaim memory in between.
  • If your project has a lot of file data, use LZ4 to compress it (-s LZ4=1 on emcc, and if you run the file packager separately, also --lz4 there). LZ4 decompresses so fast, there is hardly any slowdown to file access (sometimes it's actually faster).
  • Reduce compilation memory by running some code in the Emterpreter (make sure to use EMTERPRETIFY_FILE as well). But, this makes the interpreted code much slower.
  • Use dynamic linking to split the codebase into separate modules, which can reduce peak compilation memory usage compared to a single large asm.js file.
  • Use SPLIT_MEMORY, to not require a single big typed array, and not require it all up front. But, this makes code run much slower.

Some of the possible mitigations decrease speed. You might want to make two builds, a normal one, and a slower-but-more-likely-to-work one, and if the first fails, you can detect that using a cookie and then suggest the user try the alternate build.

See also Chrome-Perf-Issues for performance problems on Chrome, which may interact with the problems here.