1908634 - 16.2 - 9.93% reddit largestContentfulPaint / reddit FirstVisualChange + 3 more (Android) regression on Thu July 11 2024

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P1)

Description

[Florin Bilt]

Perfherder has detected a browsertime performance regression from push c0a1dfa67c6751c0f386fb9cb6339bcdd8250b64. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)	Performance Profiles
16%	reddit largestContentfulPaint	android-hw-a51-11-0-aarch64-shippable-qr	cold webrender	244.88 -> 284.57	Before/After
15%	reddit largestContentfulPaint	android-hw-a51-11-0-aarch64-shippable-qr	cold webrender	253.49 -> 291.70	Before/After
15%	reddit FirstVisualChange	android-hw-a51-11-0-aarch64-shippable-qr	cold webrender	340.53 -> 390.68	Before/After
14%	reddit fcp	android-hw-a51-11-0-aarch64-shippable-qr	cold webrender	217.90 -> 249.03	Before/After
10%	reddit FirstVisualChange	android-hw-a51-11-0-aarch64-shippable-qr	warm webrender	196.80 -> 216.34	Before/After

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the patch(es) may be backed out in accordance with our regression policy.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run these tests on try with ./mach try perf --alert 1337

For more information on performance sheriffing please see our FAQ.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1844563

Comment 2

[Paul Zühlcke [:pbz]]

Looking! The performance profile links from comment 0 are not working so I've triggered them on try.

Without having looked at any of the profiles yet, I suspect that adding the remote settings collection in Bug 1844563 creates overhead when the first page loads and the remote exception list is initialized. Here is the flow:

1. Browser starts up
2. The first navigation to a site with matching scheme (http/https) happens. This initializes BounceTrackingProtection
3. As part of BTP init we construct and initialize the remote exception list: https://searchfox.org/mozilla-central/rev/b220e40ff2ee3d10ce68e07d8a8a577d5558e2a2/toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtection.cpp#160
4. The remote exception list initializes async by calling .get on on the RemoteSettings client: https://searchfox.org/mozilla-central/rev/b220e40ff2ee3d10ce68e07d8a8a577d5558e2a2/toolkit/components/antitracking/bouncetrackingprotection/BTPRemoteExceptionList.sys.mjs#37,87
   This is most likely the piece that's slowing us down. AFAIC the RemoteSettings client needs disk access.

Comment 3

[Paul Zühlcke [:pbz]]

Since we don't strictly need the allowlist until the first purge which happens 1 hour after startup we can defer initializing it a bit. Note that we can't initialize it on purge though because we will need sync access to the list. This is all theoretical so far still because I haven't been able to get a performance profile yet.

Comment 4

[Paul Zühlcke [:pbz]]

This work is currently blocked on infra issues in our CI. I currently can't run the performance tests on try.
I'll try to run them locally to work around this, but for proper validation we'll need try.

Comment 5

[Paul Zühlcke [:pbz]]

Attachment: Bug 1908634 - Lazily initialize BTPRemoteExceptionList. r=#anti-tracking!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0670501299f9
Lazily initialize BTPRemoteExceptionList. r=anti-tracking-reviewers,bvandersloot

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/0670501299f9