Open mykmelez opened 9 years ago
Is this before or after the removal of the ref
array?
Is this before or after the removal of the ref array?
This is after its removal. I'm comparing my master-disable-compiler branch, which is the master branch with this small set of changes to disable the compiler, against my intex-jit-disable-compiler branch, which is @brendandahl's intex-jit branch with this change to disable the compiler.
Memory usage can easily be changed by tuning ASMJS_TOTAL_MEMORY. We currently allocate 134,217,728bytes. Seems to start fine and run with 16,777,216.
Setting _ASMJS_TOTALMEMORY to 16*1024*1024
reduces jsObjectsSize significantly, although memory usage is still higher in the startup benchmark:
Test | Baseline Mean | Mean | +/- | % | P | Min | Max |
---|---|---|---|---|---|---|---|
startupTime | 2,012ms | 1,318ms | -694ms | -34.51 | BETTER | 1,281ms | 1,366ms |
vmStartupTime | 210ms | 171ms | -38ms | -18.24 | BETTER | 156ms | 186ms |
bgStartupTime | 55ms | 38ms | -17ms | -31.65 | BETTER | 36ms | 45ms |
fgStartupTime | 1,315ms | 856ms | -459ms | -34.88 | BETTER | 793ms | 900ms |
fgRefreshStartupTime | 433ms | 253ms | -180ms | -41.61 | BETTER | 221ms | 319ms |
fgRestartTime | n/a | NaNms | n/a | n/a | n/a | Infinityms | -Infinityms |
totalSize | 25,416kb | 38,525kb | 13,109kb | 51.58 | WORSE | 38,182kb | 38,775kb |
domSize | 160kb | 161kb | 1kb | 0.37 | SAME | 161kb | 161kb |
styleSize | 375kb | 375kb | 0kb | 0.00 | SAME | 375kb | 375kb |
jsObjectsSize | 17,521kb | 32,977kb | 15,456kb | 88.21 | WORSE | 32,974kb | 32,981kb |
jsStringsSize | 438kb | 410kb | -28kb | -6.42 | BETTER | 410kb | 410kb |
jsOtherSize | 6,698kb | 4,378kb | -2,319kb | -34.63 | BETTER | 4,038kb | 4,628kb |
otherSize | 223kb | 223kb | 0kb | -0.12 | BETTER | 223kb | 223kb |
USS | n/a | NaNkb | n/a | n/a | n/a | Infinitykb | -Infinitykb |
peakRSS | 311,997kb | 336,545kb | 24,547kb | 7.87 | WORSE | 325,184kb | 361,532kb |
But perhaps this isn't a fair comparison, since the intex branch preallocates all memory for the VM heap in advance. A better metric would compare memory usage over the application's lifetime. @marco-c mentioned that his tests suggest WhatsApp never uses more than about 30MB, so if we were to set _ASMJS_TOTALMEMORY to, say, 32*1024*1024
and watch memory usage while using the app, then we might have a better sense of max memory usage on the intex branch.
(We might also be able to keep _ASMJS_TOTALMEMORY at 16*1024*1024
with more aggressive garbage collection or other strategies. We haven't tuned the new interpreter for memory usage yet, and there may well be significant headroom.)
As far as I know, we currently have 2
asm.js heaps. One for the relooper, and one for Boehm GC. We should compile these two C/C++ codebases together so they can share the same heap.
But perhaps this isn't a fair comparison, since the intex branch preallocates all memory for the VM heap in advance. A better metric would compare memory usage over the application's lifetime.
There's a different Emscripten option that allows growing the heap automatically, but AFAIK it's slower. It also doesn't allow actually releasing memory (see https://bugzilla.mozilla.org/show_bug.cgi?id=855669).
@marco-c mentioned that his tests suggest WhatsApp never uses more than about 30MB, so if we were to set ASMJS_TOTAL_MEMORY to, say, 32_1024_1024 and watch memory usage while using the app, then we might have a better sense of max memory usage on the intex branch.
Yes, I tested running WA for a while and its heap never grew to more than 20-30 MB (I don't recall precisely, but I can test again).
As far as I know, we currently have 2 asm.js heaps. One for the relooper, and one for Boehm GC. We should compile these two C/C++ codebases together so they can share the same heap.
Right: https://github.com/mozilla/pluotsorbet/issues/1615. The relooper's heap is quite small though, 512 kB.
(We might also be able to keep ASMJS_TOTAL_MEMORY at 16_1024_1024 with more aggressive garbage collection or other strategies. We haven't tuned the new interpreter for memory usage yet, and there may well be significant headroom.)
There's a Boehm option for small heap sizes that could be interesting: https://github.com/mozilla/pluotsorbet/issues/1627
With #1787, #1785 and #1784, the heap grows to a maximum of 2162688 bytes (I've performed a quick test, it could be more if we use WA more). We should re-run the startup benchmark once they land.
We need to test more and improve memory usage on the intex branch, but we're now definitely better than the first picture depicted in https://github.com/mozilla/pluotsorbet/issues/1780#issue-99267917.
On the startup benchmark, with the compiler disabled, the intex branch is much faster than master at starting WhatsApp, but memory usage is way up, because jsObjectsSize has ballooned: