Open Bug 1497997 Opened 2 years ago Updated 8 months ago

[meta] GeckoView performance telemetry metrics


(GeckoView :: General, enhancement, P3)

51 Branch


(Not tracked)


(Reporter: esawin, Unassigned)


(Blocks 1 open bug)


(Keywords: meta)

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?
Flags: needinfo?(vchin)
Flags: needinfo?(snorp)
Flags: needinfo?(dbolter)
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.
Flags: needinfo?(snorp)
Depends on: 1499418
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:


For e10s this is RSS [1] chrome process + USS [2] of child processes, it's pretty useful for calculating overall impact. Single process this is just the RSS.


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.


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.


This is the VSS [3] (virtual set size) of each process. It's most useful for measuring impact on 32-bit processes due to limited address space.


This is probably windows only, it helps identify problems with address space fragmentation (particularly on 32-bit).

Flags: needinfo?(erahm)
Summary: GeckoView performance telemetry metrics → [meta] GeckoView performance telemetry metrics
Product: Firefox for Android → GeckoView

Vicky, we do have some new GV-specific page load and startup performance probes.
I can add them to the Android health dashboard if you agree that they are useful to track regressions.

Flags: needinfo?(vchin)
Flags: needinfo?(vchin)

Eugen, the performance team is using these 5 telemetry probes to track page loads on desktop ATM:


Can you let me know more about how GV_PAGE_LOAD_PROGRESS_MS relates to these existing probes? If you can track FX_PAGE_LOAD_MS_2 in this dashboard then yes, that would be useful.

Ideally, desktop and mobile would share a common naming schema for these stuff (maybe even using the W3C navigation timing names!) instead of the current split.

Can you send me more background info (email is fine) about how you are getting these performance probes out of GV on android? mozconfig, and prefs or configs, logs, etc. Thanks!

Flags: needinfo?(vchin)
Blocks: 1454477

I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:


Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.