Andrew McCreight [:mccr8] Reporter
	Description • 6 years ago

This may not be a realistic idea or may overlap with some work already in progress, but it seems unfortunate to me that every content process spends a few hundred kb of memory storing preferences that are going to be identical in every content process, and are almost completely identical in every instance of Firefox. It feels like we could have a statically allocated table of default pref values, which would let them be shared between all processes, or maybe the parent process could load it up once and for all and share it with the children. I guess this could leak information between content processes about which prefs are being read but I can't imagine that mattering too much.

	Nicholas Nethercote [inactive]
	Comment 1 • 6 years ago

It's a good idea and I'm heading in this direction. The major difficulty is that prefs are currently fully dynamic -- initialized at runtime by reading prefs data files.

Bug 1436655 is a first step: it defines a subset of prefs statically, though it doesn't actually store the pref data used at runtime statically. (Doing that is listed as "future work" in the commit message.)

One complication is that people using artifact builds don't want to compile C++ code, so front-end prefs can't be done this way. (Or we can do some tricks specific to development build to get around this; telemetry just added such tricks so that new scalars could be added without recompiling local builds.)

	Eric Rahm [:erahm]
	Comment 2 • 6 years ago

Roughly guessing 600K as that's a lower bound for what I'm seeing in about:memory. Nick, what's the status on this? Is it blocked on anything?

	Nicholas Nethercote [inactive]
	Comment 3 • 6 years ago

The obstacle mentioned in comment 1 -- relating to front-end development -- still applies.

The other problem is that we have *so many prefs*, literally thousands of them. I've been avoiding even converting the VarCache ones to the new static form, because it's really tedious. And there are only a few hundred of them, and the benefits of converting VarCache prefs are higher.

Here's an old estimate of pref memory usage, from https://docs.google.com/document/d/1V5Wc9bXwfgMG2JOsswvDPVwZl_xiaSBxwJXf3fiEaU8/:

> Memory usage (all repeated in the parent process and every content process)
> * Prefname is dup’d into an arena (all prefs): 120 KiB in all processes.
> * Hashtable entries: 32 bytes per entry (all prefs): 256 KiB (~3200 prefs requires
>   a table with 8192 entries)
> * String pref values are strdup’d: 37 KiB
> * Prefs with callbacks: CallbackNode is 40 bytes on 64-bit, plus prefname is strdup’d
>   again: 50--180 KiB, varying across processes.
> * Prefs with observers: like prefs with callbacks, plus a PrefCallback which is 64
>   bytes(?) on 64-bit in a hashtable: 10--90 KiB.
> * Total: 512--700 KiB per process.

I think this is now a bit out of date, and some parts are a bit better. But still, statically allocating prefs only helps with some of those points. I suspect we'd get better bang for the buck by simply eliminating as many prefs as possible. That would help with memory and also various other things, such as complexity, IO costs at start-up and when changing, etc. It also doesn't cause problems for frond-end devs.

	Nicholas Nethercote [inactive]
	Comment 4 • 6 years ago

Bug 1471025 implemented sharing in a different way.