hbos@, is this part of the work you are doing on stats?

qaz, stats are exposed to the web. We need to standardize in order to move away from "goog" specific stats. This is the spec: https://w3c.github.io/webrtc-stats/

There is an ongoing effort the replace the current non-spec compliant getStats (which is callback-based) with a spec-compliant getStats (which is promise-based). New getStats is currently behind an experimental flag and it's actively being developed to be more complete.

When we want to add new stats we should:
1. Figure out if we want to add this value to the spec.
2. Come up with a definition of the value that we want to add to the spec.
3. Submit an issue to github.com/w3c/webrtc-stats saying what and where.
4. Wait a couple of days for feedback, create a CL (or PR for pull request), wait some more, ask for the changes to be merged.

Because the old getStats is a mess where people have been adding new things willy-nilly we could keep doing that for experimentation, but we shouldn't add new things to it that we have no intention of standardizing. Ideally the old getStats will go away.

We're working on solutions for enabling experimentation of stats in the new getStats API too but that discussion is ongoing. During a transition period we might want to add stats to both old and new getStats, or only to old getStats if experimenting.

Reassigned to qaz to figure out (1) and (2), i.e. do we want to standardize this (why, why not)? Do we have a more specific definition about "memory usage data"?

Memory usage stats like these should be available from generic APIs without going through getStats. Can you check with the chrome folks near you?

http://stackoverflow.com/questions/18455644/programatically-get-memory-usage-in-chrome seems like the right stackoverflow question.

Only if there were an API outside of WebRTC that worked... Yes, I did test the performance.memory API before filing this bug. It was not reliable at all: the numbers did not match what the Chrome task manager showed -- they did not even change when I had one participant in the video conference and 30 participants, which from Chrome tracing it's just impossible.

Who are the Chrome folks near me? I have no clue.

So maybe this should be to figure out the story behind performance.memory?

I found that for performance.memory to work for us, we would have to start Chrome with the command line argument --enable-precise-memory-info.

This won't work for our usecases: we can't practically require everybody who runs our meeting product to start the Chrome process in a certain way.

Is it possible to request Chrome to turn on precise memory info from Javascript? Does turning on precise memory info have any runtime performance impact? If so, how much?

yurys@: I noticed that you wrote code related to the --enable-precise-memory-info flag. Can you provide an answer to #8?

yurys@ doesn't seem to be active in Chromium. Guido can you find someone else to answer?

It seems like we came to the conclusion that this is not a WebRTC specific issue, but a generic memory tracking issue that is related to performance.memory. That seems to be already discussed at  issue 326370 . qaz@ feel free to mark this as duplicate and ping that issue if you agree. 

Agreed.

Thank you for providing more feedback. Adding requester "anatolid@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

OK since  issue 326370  has been marked "won't fix" and an even lower-resolution memory usage stat will be provided (https://github.com/WICG/memory-pressure/blob/master/explainer.md) instead, this becomes a standalone issue for WebRTC.

"memory usage data (Js, process, system)" does not sound like a good fit for WebRTC's getStats to me. I'd also want to avoid adding arbitrary things to getStats since one of the key goals of getStats is to be fast and fetching this information will not be fast, especially not in Chrome where several process hops in and out of the sandbox, would be required. It's not clear to me how much work it would be to split the data between system, process and js, why WebRTC is the appropriate place to do so.  Lastly, the stats provided by getStats, are available in standalone WebRTC where there might be no JS, which points to the user agent/application being responsible for this data in any case.

I'm marking this issue as a WontFix since I don't see it moving along as currently proposed. I'd rather look into adding this sort of data in e.g. an extension API where system information such as CPU usage is provided.