510ms regression to visual completeness, MAIN

[mcomella]

In my analysis, I found that visual completeness on a MAIN intent regressed 510ms after the focus architecture refactor. Let's identify why and what wins we can find.

Since the analysis, we've improved by 97ms via https://github.com/mozilla-mobile/focus-android/issues/5102. That leaves 413ms remaining.

Here are some profiles:

• before refactor: https://share.firefox.dev/3fW5J7Q
• after refactor: https://share.firefox.dev/3iFn6LU
• after refactor + 97ms improvement (taken on local build?): https://share.firefox.dev/3CIbLmt
• fenix, for comparison: https://share.firefox.dev/3CPxBEH

[jonalmeida]

Thanks for the profiles. Comparing the 'after refactor + 97ms improvement' against the 'before refactor', I've left a short comparison:

• About +190ms increased from the BrowserToolbar that was previous only the InlineAutocompleteEditText.
• Application class grew: +215ms
  • Store creation adds 27ms more than before because we're now using it with multiple features and middlewares.
  • GleanMetrics.Pings adds 45ms (previously 13ms with the TelemetryWrapper only; not a fair comparison to look at the delta)
  • Eager creation of Gecko/Client for Telemetry adds 40ms.
  • Crash reporter adds 34ms.

That adds up to the remaining ~413ms you are seeing.

[jonalmeida]

Some notes on possible next actions:

About +190ms increased from the BrowserToolbar that was previous only the InlineAutocompleteEditText.

I think Fenix doesn't use the BrowserToolbar for the homescreen until you tap on a placeholder that looks like it. We could consider that too.. I think we wanted to step away from that behaviour though.

Eager creation of Gecko/Client for Telemetry adds 40ms.

It's eager because we're still using the deprecated service-telemetry library along side Glean for now to compare the data we receive from both clients before the remove the former and the service-telemetry wasn't optimized for using the fetch client lazily. We should really be removing this deprecated telemetry client ASAP though and migrating over to Glean entirely.

GleanMetrics.Pings adds 45ms (previously 13ms with the TelemetryWrapper only; not a fair comparison to look at the delta)

We're calling registerPings correctly, but comparing it to the Fenix profile, it looks like we need to move the whole initialization to happen later in the activity lifecycle? Needs more investigation (how do we track metrics before the activity then?)

[mcomella]

Side note: if we make improvements here, maybe we can make the same improvements to fenix.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cpeterso]

Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1802663

Change performed by the Move to Bugzilla add-on.