When a lock only queues get requests, there is no need to open a readwrite transaction. This could help speedup things.

Whenever a settings lock does only read operations (i.e. lock.get()), there is no need that the underlying indexedDB transaction should be opened as readwrite. Doing so, we will be able to parallelize some request and avoid locking that should in the end allow for faster operations.

Comment on attachment 8534897 [details] [diff] [review] Open readonly transaction for settings lock when possible r=qdot Review of attachment 8534897 [details] [diff] [review]: ----------------------------------------------------------------- r+ with expansion of comment. ::: dom/settings/SettingsRequestManager.jsm @@ +119,5 @@ > // Lets us know if this lock has been used to clear at any point. > hasCleared: false, > + // Whether we want to do a read only transaction. Define be default, and let > + // queueTask() set this to false if we queue any "set" task. > + forceReadOnly: true, We should expand this to explain the assumption we're making. Something like: forceReadOnly sets whether we want to do a read only transaction. Define true by default, and let queueTask() set this to false if we queue any "set" task. Since users of settings locks will queue all tasks before any idb transaction is created, we know we will have all needed information to set this before creating a transaction.

Whenever a settings lock does only read operations (i.e. lock.get()), there is no need that the underlying indexedDB transaction should be opened as readwrite. Doing so, we will be able to parallelize some request and avoid locking that should in the end allow for faster operations.

Rebased on top of master, and updated the comment.

Try: https://tbpl.mozilla.org/?tree=Try&rev=5d8ea303ee5b&showall=1

Whenever a settings lock does only read operations (i.e. lock.get()), there is no need that the underlying indexedDB transaction should be opened as readwrite. Doing so, we will be able to parallelize some request and avoid locking that should in the end allow for faster operations. Enabling this feature is controlled by the preference dom.mozSettings.allowForceReadOnly, defaulting to false for now.

Comment on attachment 8537740 [details] [diff] [review] Open readonly transaction for settings lock when possible r=qdot Hiding this behind a pref, so that we can land and ask a set of people to dogfood and/or easily toggle off. I've been using it on some devices for several days, but given how critical settings is, I'd prefer that we bake it properly.

Try with pref off: https://tbpl.mozilla.org/?tree=Try&rev=34aed7bd49a5

Try with pref on: https://tbpl.mozilla.org/?tree=Try&rev=4b80904713e8

Comment on attachment 8537740 [details] [diff] [review] Open readonly transaction for settings lock when possible r=qdot Review of attachment 8537740 [details] [diff] [review]: ----------------------------------------------------------------- r+ with comments addressed ::: b2g/app/b2g.js @@ +1073,5 @@ > + > +// Controlling whether we want to allow forcing some Settings > +// IndexedDB transactions to be opened as readonly or keep everything as > +// readwrite. > +pref("dom.mozSettings.allowForceReadOnly", false); This and the debug prefs above it should also be added to modules/libpref/init/all.js.

Whenever a settings lock does only read operations (i.e. lock.get()), there is no need that the underlying indexedDB transaction should be opened as readwrite. Doing so, we will be able to parallelize some request and avoid locking that should in the end allow for faster operations. Enabling this feature is controlled by the preference dom.mozSettings.allowForceReadOnly, defaulting to false for now.

Comment on attachment 8537879 [details] [diff] [review] Open readonly transaction for settings lock when possible r=qdot Should be addressing latest comment.

Comment on attachment 8537879 [details] [diff] [review] Open readonly transaction for settings lock when possible r=qdot Review of attachment 8537879 [details] [diff] [review]: ----------------------------------------------------------------- r+ with comments addressed. Which means you don't have to ask for r? again. :) ::: modules/libpref/init/all.js @@ +4420,5 @@ > +// MozSettings debugging prefs for each component > +pref("dom.mozSettings.SettingsDB.debug.enabled", true); > +pref("dom.mozSettings.SettingsManager.debug.enabled", true); > +pref("dom.mozSettings.SettingsRequestManager.debug.enabled", true); > +pref("dom.mozSettings.SettingsService.debug.enabled", true); You want all of these off by default here, most likely.

Whenever a settings lock does only read operations (i.e. lock.get()), there is no need that the underlying indexedDB transaction should be opened as readwrite. Doing so, we will be able to parallelize some request and avoid locking that should in the end allow for faster operations. Enabling this feature is controlled by the preference dom.mozSettings.allowForceReadOnly, defaulting to false for now.

Comment on attachment 8537924 [details] [diff] [review] Open readonly transaction for settings lock when possible r=qdot Carrying r+ from :qdot, just changing values of debug prefs.

See try in comment 8