A glance into the exact way heap size is determined

[gagiopapinni]

I would like to better understand how heap size is determined exactly

For instance, when using performance.memory api in chrome, under the name of usedJSHeapSize it seems to return the allocated heap size, although certain sections of that heap portion may be not used by the app at that moment.
This results in the inability to track rigorously every byte that is used by the app to later evaluate optimization efforts.

However memlab seems to return much smaller heap sized compared to performance.memory.
I suppose it means that memlab does a more precise measurement of the portion of the heap that is actually used by the app.

In this context I would want to better understand the mechanics which memlab uses to calculate the heap size

If I put all of this into two question, it would be like this:

• Does memlab give a precise measurement of the actual portion of the heap that is used by the app?
• If I regularly(say with every merged pr) collect statistics of heap size utilizing memlab, would it be accurate enough to evaluate optimization efforts based on that? (if not, what would be the way to do that?)

[JacksonGL]

However memlab seems to return much smaller heap sized compared to performance.memory.

performance.memory queries the current heap size without running the garbage collector (GC); so it's very fast, but the memory number is bloated. The heap size number in MemLab should be more accurate since MemLab enforces the GC before querying performance.memory and then reports the number to the console. The heap snapshot taken also contains heap size info, which should be more accurate than the number queried from performance.memory.

Does memlab give a precise measurement of the actual portion of the heap that is used by the app?

One thing worth noting is that the performance.memory API and the heap size number from heap snapshots are all trying to measure the JavaScript heap size. There is a non-trivial part of the browser memory not reported by any of those Chrome APIs (e.g., rendering process's memory usage, some parts of the DOM memory, and some native components' memory consumption).

Therefore, the heap size reported by MemLab is more accurate than the performance.memory API you query from web console manually (if you don't run GC). The number is precise in terms of JS heap size, but there is other "invisible" memory not reported.

If I regularly(say with every merged pr) collect statistics of heap size utilizing memlab, would it be accurate enough to evaluate optimization efforts based on that? (if not, what would be the way to do that?)

There are lots of sources of noise that could affect the heap size number. For example, GC in JS engine, JIT, and the non-determinism in the web app itself. So even if you measure the same app twice without any optimization, you may get different heap sizes due to the noise.

The best way to evaluate optimization efforts is to A/B test in production and see if there are stat-sig improvements.

If you have to measure the memory change locally, the improvement has to be bigger than the noises to confirm. I would recommend a very big sample size on both control group and treatment group to make the stat-sig test meaningful. Also keep in mind that your local test account may not be representative and the memory consumption may be biased towards your local app's config, browser version, network, i18n etc.