Large amounts of data stored in prefs.js

RESOLVED INCOMPLETE

Status

Tech Evangelism
Add-ons
--
minor
RESOLVED INCOMPLETE
5 years ago
5 years ago

People

(Reporter: alanjstr, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
Several add-ons store large amounts of data in prefs.js which could slow start-up.  Is this the optimal place for them to store their data?

Examples:
NoScript
HTTPS Everywhere
Social Fixer
What makes you think that stored preferences slow startup in any meaningful way?
(Reporter)

Comment 2

5 years ago
I am not saying it is a significant slowdown, only assuming that loading all the name value pairs and parsing them during startup might consume some milliseconds.  If this has already been studied, then I apologize.  I was just looking at my own prefs.js and saw that some add-ons have more than 100 entries, and some have string data 70,000 characters long.
I doubt it adds anything significant. Firefox has hundreds if not thousands of preferences of varying lengths, so loading a few more probably doesn't hurt.

An easy experiment to do would be to create an extension that only has a bunch of large prefs, and measure it's startup performance (https://developer.mozilla.org/en/Measuring_Add-on_Startup_Performance). If you come up with any stats that show a significant slowdown, then we will have something to work with.
In the case of NoScript, I'd say preferences are really not the best place to store its data, regardless of the impact on startup time. I think that NSA moved away from that in any case. Nevertheless, unless there's some evidence that it's an issue, I wouldn't worry about it. prefs.js is loaded once at startup from native code and stored in memory, and the writeouts when preferences are changed are somewhat lazy, so the amount of data doesn't matter nearly as much as the number of preferences written.

Unfortunately, given the nature of the prefs.js format, any change does require the entire file to be written out from scratch, so there may be some runtime performance penalties to huge flies. But, again, without some evidence of of a problem, I don't think we should worry about it. Resolving INCOMPLETE until then.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.