Open Bug 1497997 Opened 2 years ago Updated 8 months ago
View performance telemetry metrics
Let's discuss the telemetry probes that would be useful for our GeckoView performance dashboard in this bug. We can handle adding additional probes in dedicated bugs if required. 1. Startup time: It's tricky to account for all the different GV usage scenarios for this metric. To start, we could track the time between the initialization of the runtime and the Gecko-ready state. 2. Actual page load time: Adding the GV-equivalent probe to FX_PAGE_LOAD_MS would give us the overall (non-dynamic) page load time metric. There are existing Gecko probes that track this time, but are either not sent or are in some other way less useful on mobile, e.g., TOTAL_CONTENT_PAGE_LOAD_TIME tracks a useful time, but has its limit set too low at 30s. We probably want to control this probe to ensure that it's directly relatable to the perceived page load time probe. 3. Perceived page load time: The goal of the progress tracker (ProgressDelegate.onProgressChange) is to track and signal the perceived page load progress. We should add a probe to track load completion times. This probe will also be useful for the validation and tweaking of the signals used to track the perceived load progress. TIME_TO_NON_BLANK_PAINT_MS is also a useful probe to track the time to the initial non-blank paint. 4. Memory usage: There are a number of MEMORY_* candidate probes, we should look into which provides the strongest signal on mobile. Do this metrics cover the performance fundamentals we care about? Are there existing better suited probes than the ones suggested?
Sounds reasonable to me. I think James and Vicky will have more interesting comments. Adding Anthony because he probably has good ideas about measuring memory.
Flags: needinfo?(dbolter) → needinfo?(ajones)
I think this is a good start. I'd also like to know about child process startup time, so we should factor that into the startup stuff.
2 years ago
Priority: -- → P2
Eric can advise on memory probes.
Flags: needinfo?(ajones) → needinfo?(erahm)
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #3) > Eric can advise on memory probes. I'd need more details on how geckoview works. Is it in it's own process, or a library in another process? All the MEMORY_* metrics are process-centric which makes sense for measuring Firefox as a whole, but if you're embedded in another process it will include that process' memory too. I'll breakdown the measurements for you: *MEMORY_TOTAL* For e10s this is RSS  chrome process + USS  of child processes, it's pretty useful for calculating overall impact. Single process this is just the RSS. *MEMORY_UNIQUE* This is just the USS of each process (not summed). This might be useful if you are using content processes, but embedded in a parent process. It's filterable by process type. *MEMORY_UNIQUE_CONTENT_STARTUP* This is the USS of each content process at startup. It's useful for measuring the baseline overhead of each process. We're using it for fission memshrink work. *MEMORY_VSIZE* This is the VSS  (virtual set size) of each process. It's most useful for measuring impact on 32-bit processes due to limited address space. *MEMORY_VSIZE_MAX_CONTIGUOUS* This is probably windows only, it helps identify problems with address space fragmentation (particularly on 32-bit).  https://en.wikipedia.org/wiki/Resident_set_size  https://en.wikipedia.org/wiki/Unique_set_size  https://en.wikipedia.org/wiki/Virtual_memory
Summary: GeckoView performance telemetry metrics → [meta] GeckoView performance telemetry metrics
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.