62755 - prefs files need to be partitioned / factored

Status: RESOLVED DUPLICATE of bug 224578

(Core :: Preferences: Backend, defect, P3)

Description

[Judson Valeski]

Currently an embedding app needs to include all.js, initprefs.js, and 
[OS]pref.js. all.js in particular contains many preferences that don't pertain 
to embedding scenarios. For example, current embedding clients don't need 
mailnews preferences.

Should modules using/needing prefs provide their own prefs file and export it to 
a prefs directory (part of the build process would be to cobble them all 
together at the end)?

Comment 1

[Alec Flett]

yes, we need to move prefs out of modules/libpref/src/init and into their
respective modules. all.js can be broken up into a few files as well.
cc mcafee since he's often interested in this stuff

Comment 2

[Judson Valeski]

I'm nominating this for 0.8. Until this is fixed, we'll have to push every pref
under the sun around to embeddors. On top of confusion, each pref yields
overhead in the pref subsystem.

Comment 3

[timeless]

i'm working on this, but i'll need to ignore bugmail to finish. and i'm only 
factoring wallet atm.

Comment 4

[Judson Valeski]

over to timeless (_THE_ man!). please note the 0.8 nomination.

Comment 5

[Judson Valeski]

adding jag to cc list.

We haven't really spent time thinking about how to paritition this stuff. But
some toplevel modules I'd seperately package would be I'd make would be.

JS/CAPS
necko
xpfe*
mail/news
i18n
l10n
layout

Comment 6

[timeless]

ok. time to reduce my bugmail intake.

Comment 7

[sairuh (rarely reading bugmail)]

from a QA perspective, where would/should these pref files end up? ie, would
they be moved out of default/prefs/ and if so, where? thx!

Comment 8

[Judson Valeski]

I suspect they'll all still wind up in default/prefs, it's just that we'll have
several files rather than just a few. That way, if we're not shipping component
foo, foo's prefs don't have to be shipped either.

Comment 9

[Simon Fraser [no longer active]]

Note that loading in the prefs files is a significant proportion of startup time. 
Please try and keep the number and size of the prefs files to a minimum.

Comment 10

[Judson Valeski]

good point. hmmm. we need to somehow consolodate all the files after a full
build, into a single (or fewer) prefs files. Thoughts?

Comment 11

[timeless]

Attachment: patch

Comment 12

[Judson Valeski]

excellent! r=valeski. Are we already cobbling .js files together at build time?

Comment 13

[Blake Ross]

Umm...wasn't one of the main goals of 33115 to keep pref loading to a minimum?  
I'd rather this not go in until we work out the consolidation.

(btw, +    $(MAKE_INSTALL) .\init\siderbar.js $(DIST)\bin\defaults\pref -- 
siderbar?)

Comment 14

[Conrad Carlen (not reading bugmail)]

I think we need some performance numbers. First - for SeaMonkey which reads the
most prefs - is there a performance hit for interpreting a number of smaller
prefs files instead of all.js? I doubt it, but let's find out. Unless there is a
noticable hit we should do this because splitting the files makes it easier for
an embedding app to build a dist. 

Comment 15

[Judson Valeski]

33115 is about removing obsolete prefs entries.

There will certainly be more overhead w/ new file opening/reading/closing going 
on. I've filed http://bugzilla.mozilla.org/show_bug.cgi?id=66877 to address the 
consolodation of prefs files, post build.

This bug is seperate and stands on it's own. Let's move forward w/ a sr= on this 
one and get it in.

Comment 16

[Alec Flett]

sr=alecf

at some point (or as part of this bug) we should be moving the individual .js
files into their respective module's directories

i.e. modules/libpref/src/init/mailnews.js should probably end up in
mailnews/base/prefs/mailnews.js or something similar.

Comment 17

[Judson Valeski]

let's move them out here. timeless, can you make that last revision?

Comment 18

[Chris McAfee]

see bug 66877, opening of pref files is expensive.?
Something to think about in terms of speeding up startup.

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

I applied Timeless' patches and crashed at startup in necko.dll

NS_IMETHODIMP
nsFileIO::GetName(char* *aName)
{
   return mFile->GetPath(aName);
}

Comment 20

[timeless]

current plans for new locations:

all.js
browser.js => xpfe/browser
necko.js => netwerk
sidebar.js => xpfe/components/sidebar
i18n.js => intl
wallet.js => extensions/wallet
mailnews.js => mailnews
editor.js => editor
config.js

ok, the things that are left are [in all.js] of the following types:
images font general signed image clipboard middlemouse css mousewheel profile 
converter silentdownload security advanced prefs nglayout ui imageblocker 
javascript autoupdate

remove [4.x only]:
pref("autoupdate.enabled",              true);
silentdownload.*

belongs in maybe ui.js:
font.*
css.*
middlemouse.*
mousewheel.*

what do people want to do with the others?

as stephend found, my patch can't be committed until bug 66877 is fixed.

Comment 21

[timeless]

cc module people, please raise your objections here ASAP.  If there are none, 
then I'll make the changes as soon as bug 66877 lands.

Comment 22

[Stephen P. Morse]

I see that you've put the cookies prefs into necko.js.  But the cookie module is 
in extensions/cookie and supposedly could be left out of an installation.  But 
in that case the cookie prefs would still be present.

Comment 23

[Judson Valeski]

I think cookies is an edge case. two options:
1. cookies gets it's own cookies.js file
2. we eat the overhead in the *really* off chance that cookies and necko get 
seperated.

Comment 24

[timeless]

filed bug 67281 for cookies.

Comment 25

[Gagan]

<nitpick> Consider renaming necko.js to network.js. Necko was a code 
name and network is more descriptive.</nitpick>

Comment 26

[Chris McAfee]

yes, we should do network.js

Comment 27

[timeless]

yes done, any other things i need to do?  maybe i should work on bug 66877.

Comment 28

[timeless]

Attachment: refactor into .jsf files and use rules.m*k to join

Comment 29

[Asa Dotzler [:asa]]

Are you still shooting for 0.9 on this?  Do you think that you'll have the two
dependencies fixed in the next day or two?  If so please email
[e-mail] with a status on you progress. If not please retarget
against a later Milestone. Thanks.

Comment 30

[timeless]

slipping.  Beard/JJ, I need help on the mac side. When can I get it?

Comment 31

[chris hofmann]

beard's on vacation, jj soon to be swamped with 0.9.1 release work.
this kind of change would be better early in a milestone, right?

Comment 32

[chris hofmann]

I'm going to unset the target milestone until we get a good
estimate on all the platforms...  this sorta looks like a landing
plan thingy, right?

if we go with separate files we need impact on startup perf numbers.

Comment 33

[chris hofmann]

this one seems to be sliding.. lets try to give it a realistic milestone. 
thanks - chofmann

Comment 34

[Winnie Lam]

minusing this bug as per edt triage, but we'll take out the minus from topembed-
if the fix is available in the next few weeks.  

Comment 35

[Juan José Mata]

EDT topembed triage: topembed+ again since this should be a disk footprint win.
 Josh, please reassign if you need help on this one.

Comment 36

[Stephen Walker]

*** Bug 158594 has been marked as a duplicate of this bug. ***

Comment 37

[Dave Barrowman]

topembed minus for the time being per EDT discussion.  

Can we get an estimate of the footprint / performance win?

Comment 38

[Steffen Wilberg]

This was accomplished by bug 224578:
modules/libpref/src/init/editor.js -> editor/ui/composer.js
modules/libpref/src/init/mailnews.js -> mailnews/mailnews.js
and more...

*** This bug has been marked as a duplicate of 224578 ***