Closed Bug 1984640 Opened 5 months ago Closed 5 months ago

0.2% installer size (Windows) regression on Thu August 14 2025

Categories

(Toolkit :: Blocklist Implementation, defect)

Product:
Toolkit
Component:
Blocklist Implementation
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox-esr128 --- unaffected
firefox-esr140 --- unaffected
firefox142 --- unaffected
firefox143 --- affected
firefox144 --- affected

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: perf-alert, regression)

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

Please acknowledge, and begin investigating this alert within 3 business days, or the patch(es) may be backed out in accordance with our regression policy. Our guide to handling regression bugs has information about how you can proceed with this investigation.

If you have any questions or need any help with the investigation, please reach out to bacasandrei@mozilla.com. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Regressions:

Ratio Test Platform Options Absolute values (old vs new)
0.20% installer size windows2012-32-shippable nightly 107,298,439.54 -> 107,508,113.17

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

You can run all of these tests on try with ./mach try perf --alert 46304

The following documentation link provides more information about this command.

Flags: needinfo?(canaltinova)

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

status-firefox142: --- → unaffected
status-firefox143: --- → affected
status-firefox144: --- → affected
status-firefox-esr128: --- → unaffected
status-firefox-esr140: --- → unaffected

The code modified in bug 1981751 only exists on Linux, so a Windows installer size regression seems unrelated.

Flags: needinfo?(aryx.bugmail)

Perf sheriff question, forwarding.

Flags: needinfo?(aryx.bugmail) → needinfo?(bacasandrei)

For size regressions, you'll get a better signal from the opt builds rather then from the shippable builds.

https://treeherder.mozilla.org/perfherder/graphs?highlightAlerts=1&highlightChangelogData=1&highlightCommonAlerts=0&replicates=0&series=autoland,1921152,1,2&series=autoland,1457010,1,2&timerange=1209600&zoom=1755132825694,1755222416798,105827509.54697262,125711102.97536768

The opt build graph shows that this regression was introduced by https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=5dcc7d0e50ab17cda3e81ff63c0ab941313d2de7&tochange=9f68f9ffc4e8e41cc7ee3d3ad4f928138f0ff125 which landed with no bug. It appears to be services/settings/dumps/blocklists/addons-bloomfilters/softblocks-addons-mlbf.bin in particular which is to blame.

How many blocklist entries were added? How many bytes does each entry occupy in the bloom filter file?

Flags: needinfo?(canaltinova) → needinfo?(rob)
No longer regressed by: 1981751

This is expected. We recently softblocked many extensions, which caused the softblocks-addons-mlbf.bin file to grow from 9351 bytes to 162620 bytes.

The size of the multi-layered bloomfilter file is dependent on the number of blocked and not blocked entries, with the cardinality of the smaller set contributing the most to the file size.

Here are some examples:

  • 1k vs 4M: 3 KB
  • 10k vs 4M: 21 KB
  • 100k vs 4M: 147 KB
  • 200k vs 4M: 258 KB
  • 300k vs 4M: 355 KB
  • 1M vs 4M: 525 KB
  • 1M vs 10M: 1107 KB.

If you are interested in exploring the last (only) instance of an unexpected file size increase due to a bug in bloom filter generation, see bug 1938506.

Status: NEW → RESOLVED
Closed: 5 months ago
Component: Gecko Profiler → Blocklist Implementation
Flags: needinfo?(rob)
Flags: needinfo?(bacasandrei)
Product: Core → Toolkit
Resolution: --- → WORKSFORME
See Also: → 1938506

How much value are our users getting from having this entire bloom filter included in the Firefox build? It seems disproportionate.

Flags: needinfo?(rob)
Duplicate of this bug: 1986653

(In reply to Markus Stange [:mstange] from comment #7)

How much value are our users getting from having this entire bloom filter included in the Firefox build? It seems disproportionate.

The trade off is between guaranteed security (being certain that malicious add-ons won't run in a fresh download, even if offline) vs space savings.

For soft blocks, it may be reasonable to not bundle and await the downloaded item, since soft blocks are less severe than hard blocks.

I'm considering options to shrink the blocklist further. Two options (without loss of functionality that I think are worth pursuing are:

  • changing from multi-layered bloom filters to clubcards
  • merging the soft and hard blocks, and use an additional AMO API call to determine what kind of block is in place.

There are no tracking bugs for these yet, but if these materialize anywhere I'll link it from this bug for visibility.

Flags: needinfo?(rob)
No longer duplicate of this bug: 1986653
You need to log in before you can comment on or make changes to this bug.