Closed
Bug 160377
Opened 23 years ago
Closed 22 years ago
Prefs should have a dirty flag to avoid redundant prefs file saves
Categories
(Core :: Preferences: Backend, defect, P2)
Core
Preferences: Backend
Tracking
()
RESOLVED
FIXED
mozilla1.3beta
People
(Reporter: sfraser_bugs, Assigned: alecf)
References
Details
(Whiteboard: fix in hand)
Attachments
(1 file, 1 obsolete file)
12.10 KB,
patch
|
timeless
:
review+
dveditz
:
superreview+
|
Details | Diff | Splinter Review |
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.
Comment 1•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.2alpha
Assignee | ||
Comment 2•23 years ago
|
||
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..
Assignee | ||
Updated•23 years ago
|
Whiteboard: fix in hand
Comment 3•23 years ago
|
||
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.
Assignee | ||
Comment 4•23 years ago
|
||
mozilla 1.2alpha is more or less done. moving mozilla 1.2alpha bugs out to
mozilla 1.2beta
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Assignee | ||
Comment 5•23 years ago
|
||
These bugs missed the 1.2 train. Moving these out to 1.3alpha
Target Milestone: mozilla1.2beta → mozilla1.3alpha
Assignee | ||
Comment 6•22 years ago
|
||
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
Assignee | ||
Comment 7•22 years ago
|
||
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
Assignee | ||
Comment 8•22 years ago
|
||
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 10•22 years ago
|
||
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?
Assignee | ||
Comment 11•22 years ago
|
||
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..
Reporter | ||
Comment 12•22 years ago
|
||
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'?
Comment 13•22 years ago
|
||
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 14•22 years ago
|
||
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+
Assignee | ||
Comment 15•22 years ago
|
||
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.
Description
•