Closed Bug 160377 Opened 22 years ago Closed 22 years ago

Prefs should have a dirty flag to avoid redundant prefs file saves

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.3beta

People

(Reporter: sfraser_bugs, Assigned: alecf)

References

Details

(Whiteboard: fix in hand)

Attachments

(1 file, 1 obsolete file)

There's no way at the moment to tell if the prefs have been changed since the
last save to disk, so that we can't avoid doing redundant, and expensive file saves.

It would be useful to have something on the pref API that allows embedders to
tell if the prefs are dirty. Furthermore, perhaps a 'mod count' or numeric value
could be used so that callers can tell if the prefs have changed since some
previous time. Implementation would just incrememnt this value on every pref
change, and set it to 0 on successful file save.
I think there is a bug elsewhere about keeping track of all profile data
dirtyness, so laptops aren't constantly woken up. It was less about the
'expensiveness' and more about timing writes together when the drive is spinning
anyway, based on user activity.
Blocks: 161711
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.2alpha
Attached patch Add a "dirty" attribute (obsolete) — Splinter Review
This patch adds a new interface, nsIPrefService, which keeps track of a global
flag, gDirty, which knows whether or not the pref service is dirty or not. 

I didn't like making the flag global, but prefs is such a mess that I needed to
be able to get to it from both prefapi.cpp and nsPrefService.

in any case, I also added a warning for when we write out prefs redundantly. I
didn't want to actually prevent it from writing out the file just yet because I
think there may be strange cases that we aren't aware of just yet. I'd like to
run with this and see what happens in the comercial builds, etc..
Whiteboard: fix in hand
You are setting gDirty at the end of pref_HashPref, this will cause the state to
set dirty regardless of whether a change occured or not. It also seems redundant
as you are also setting it in pref_SetValue (which seems like the correct place
to do it.)

PREF_ClearUserPref is never setting the flag, and PREF_ClearAllUserPrefs is
setting it whether it clears anything or not (might be better to do it in the
callback, but I suppose it may not be that important).

PREF_DeleteBranch might also set the flag when nothing is deleted, but I could
live with that.
mozilla 1.2alpha is more or less done. moving mozilla 1.2alpha bugs out to
mozilla 1.2beta
Target Milestone: mozilla1.2alpha → mozilla1.2beta
These bugs missed the 1.2 train. Moving these out to 1.3alpha
Target Milestone: mozilla1.2beta → mozilla1.3alpha
moving somewhat important bugs to 1.3beta for consideration - some of these may
be bumped out to 1.4alpha after being evaluated.
Target Milestone: mozilla1.3alpha → mozilla1.3beta
this addresses brian's comments:
- gDirty is now only set when pref_HashPref results in the value changing (this
also means that is is not set when you set a pref to its current value, which
is nice)
- the default prefs file is not written when gDirty is false.
Attachment #97082 - Attachment is obsolete: true
Comment on attachment 111642 [details] [diff] [review]
Add a "dirty" attribute, v1.1

timeless/dveditz, can I get a review on this? This should help some performance
stuff, including shutdown performance since we write the prefs file out some 4
times during shutdown...
Attachment #111642 - Flags: superreview?(dveditz)
Attachment #111642 - Flags: review?(timeless)
Comment on attachment 111642 [details] [diff] [review]
Add a "dirty" attribute, v1.1

new files should be MPL/...

+   * is the pref store dirty, and possibly needs to
+   * be written to disk?
perhaps:
* Whether the pref store is dirty and therefore
* needs to be written to disk.
Attachment #111642 - Flags: review?(timeless) → review+
Comment on attachment 111642 [details] [diff] [review]
Add a "dirty" attribute, v1.1

>+                    <PATH>nsIPrefServiceInternal.idl</PATH>

Have we finally givenup on "nsPI..." names for internal interfaces?

>diff -N public/nsIPrefServiceInternal.idl

>+ * Version: NPL 1.1/GPL 2.0/LGPL 2.1

Should be the *Mozilla* PL, not Netscape, for new files. Unless you're saying
this is a derivative ("Modification") of an existing file. Couple other updates
in the license block follow from that. Whether you change the license or not
you need to update the copyright date which shouldn't be 1998 for a new file.

>+ * Contributor(s):
>+ * Alec Flett <alecf@netscape.com>
>+ * Brian Nesse <bnesse@netscape.com>

Did bnesse contribute to this new file?

>+[scriptable, uuid(79A55A09-713E-42d5-B983-5228FF501118)]
>+interface nsIPrefServiceInternal : nsISupports
>+{
>+  /**
>+   * is the pref store dirty, and possibly needs to
>+   * be written to disk?
>+   */
>+  readonly attribute boolean dirty;
>+  
>+};

I didn't see where this interface was used, looks like you use the internal
global gDirty instead (which is less overhead anyway). Can we get rid of this
interface and makefile changes?
I'll fix the license issues

but as for this new attribute, this was a request by chimera (see the top of the
bug)

Simon, how critical is it for you to have the 'dirty' attribute? We could just
hide it all inside libpref..
It would be fine to hide it inside libpref, but then what does the SavePrefFile
call do? Does it do nothing, or does it save anyway? Maybe SavePrefFile needs a
param to say 'really save'?
Why would you care if SavePrefs does nothing if there's really nothing to do?

Anyway, if you need the property then fine, but since I didn't see it used I
worried it would just be bloat (another .xpt loaded in memory everytime, etc).
Comment on attachment 111642 [details] [diff] [review]
Add a "dirty" attribute, v1.1

sr=dveditz though I'd prefer skipping the extra idl and related support until
someone demonstrates a need for it (such as linking in a bug showing a patch
ready to use it to good effect?)
Attachment #111642 - Flags: superreview?(dveditz) → superreview+
ok, I landed the patch without the nsIPrefServiceInternal stuff

as for forcing the write to disk, I'm not actually sure I see the advantage of
being able to do that in an API. Besides, nsIPrefService is frozen (Which was
the whole reason for the "Internal" version anyway)

Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: