`measureUserAgentSpecificMemory` API seems inaccurate in WASM mode

[kenzieschmoll]

Results from measureUserAgentSpecificMemory API call:
memoryUsageInBytes: 6063731579
memoryInGb: 5.647290105931461

These numbers are significantly higher then when calling this API in non-wasm mode (JS).

Taking a heap snapshot from chrome DevTools showed a significantly smaller snapshot size:

More context:

• This is happening in Flutter DevTools. I am calling the web API from these extension methods: https://github.com/flutter/devtools/blob/69090a05063deb7211ad97e9b0a1c52d8722d119/packages/devtools_app/lib/src/framework/observer/_memory_web.dart#L16

[kenzieschmoll]

CC @srujzs

[mkustermann]

These numbers are significantly higher then when calling this API in non-wasm mode (JS).

So in wasm mode DevTools uses less memory?
That would seem like a good thing, no?

In general dart2wasm and dart2js will have a different memory profile due to various reasons. The flutter counter app for example shows for me

dart2wasm:

dart2js:

I would for example totally expect dart2wasm to have smaller size spent on generated code compared with dart2js.

Taking a heap snapshot from chrome DevTools showed a significantly smaller snapshot size:

Smaller snapshot in wasm or js mode? Or snapshot size compared with the browser API?

The heap snapshot will provide statistics about memory consumption of the browser engine's managed heap (i.e. V8 heap). It may not include memory that isn't part of the managed heap but is in C memory. The browser API may include various off-heap data structures in the result of it's API call.

Also the heap snapshot tool will report it for a given V8 heap (e.g. one iframe) whereas the browser API may include it for all iframes / ... in a page.

Could that answer / explain this discrepancy?

@kenzieschmoll Is there any indication of a dart2wasm compiler issue here? (as this is labled as a dart2wasm bug)

[osa1]

Even if measureUserAgentSpecificMemory is inaccurate, it's a browser API, not dart2wasm specific. So I'm not sure what can be done about this (assuming it's inaccurate) in dart2wasm.

To have an idea of whether this could be a V8/Chrome bug, it could be useful to check with other browsers to see if they all report similar numbers with Wasm.