1819714 - Avoid sending preferences to subprocesses for performance reasons

Status: NEW

(Core :: Preferences: Backend, enhancement)

Description

[Tom Ritter [:tjr]]

Most of the work in Bug 1708798 has been about sanitizing preference values for privacy/security reasons. It built upon prior work that avoided sending preference values for performance reasons. In the sanitization work, we lost the performance gains in many places. We want to bring that back.

The amount of work needed to only send the preferences needed in each process type is prohibitive. Instead, the more reasonable approach is to blocklist preferences we know are noisy or large.

Preferences initially get into subprocesses either via an immutable large Shared Memory section on startup (sanitized preferences are omitted from this) or via a second short-lived shared memory section that represents the diff of the current prefs over the immutable snapshot. We won't change this behavior at all.

Subsequently, whenever a pref is changed, a pref update is sent. This is even the case for sanitized preferences (at least until Bug 1817297 lands shortly). It is this behavior we want to neuter.

We'd create a global pref blocklist (used for all subprocesses) and then per-process-type additional lists. If a pref is in one of these blocklists, we won't send an update to the content process. There's a SendPreferenceUpdate() function for each subprocess, we'd intercept right before there.

When we do this work, we would revert the behavior of Bug 1817297 in favor of this perf blocklist. The perf blocklist would overlap significantly with the privacy/security blocklist, but they should not rely on each other.