Starting my flame with IDB logging enabled and with no gecko or gaia upgrades I see >400 separate IDB transactions. That's a lot of db activity! I think some/most is settings reads, but we should still be able to cut this number down significantly.

Cc Bevis for the SMS part

SMS is a little weird, we load that incredibly early at startup, like from the RIL code I think. So with Julien's crazy large SMS database that he sent me we run that upgrade very early at startup and it slows down overall startup a ton. Any idea why we do that?

That's because we init the sms db early at https://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/MobileMessageDatabaseService.manifest?force=1#3 I guess we could be smarter and only init the db at first use.

(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #3) > SMS is a little weird, we load that incredibly early at startup, like from > the RIL code I think. So with Julien's crazy large SMS database that he sent > me we run that upgrade very early at startup and it slows down overall > startup a ton. Any idea why we do that? Hi, By my understanding, the upgrade happends either in 1st bootup or during new SW update if the db version is smaller than the one defined in [1]. In addition, it could be late to init the db at first use because we might have to send ACK of the status of receiving SMS in time when a new SMS was received. [1] http://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/MobileMessageDB.jsm#28

I don't think we really need to optimize for the first boot after upgrade; the user likely expects that things will settle. Or we can think the other way around: we may want to optimize it because it's the first look on a fresh version. But anyway this would not be for this bug IMO.

(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #3) > SMS is a little weird, we load that incredibly early at startup, like from > the RIL code I think. So with Julien's crazy large SMS database that he sent > me we run that upgrade very early at startup and it slows down overall > startup a ton. Any idea why we do that? Interesting. Given my SMS database, that can explain a lot of the slowdown on my dogfooding devices, especially Nexus S: > > SELECT COUNT(*) FROM object_data; > 32495

Not to mention that the last upgrade step for SMS is something like O(n^2)...

Turning on debug on Settings API, counting 'Settings:CreateLock' I find 157 for boot up to displaying the SIM PIN dialog.

And 34 CreateLock calls after unlocking PIN and up to idling on the Homescreen.

Counting the number of "Making READONLY transaction" and "Making READWRITE transaction" from logs, I see figures matching your finding earlier: 380 for the boot up to SIM PIN dialog, 77 for unlocking PIN and idling on homescreen. Specifically, I find 0 READONLY messages and all are READWRITE. Not sure if that is expected and/or it may have an impact on the performances.

99 GET transactions are coming from the use of SettingsListener.observe() in Gaia.

> 1,300 (100.0%) -- settings-locks > ├────988 (76.00%) -- tasks > │ ├──589 (45.31%) ── processed > │ ├──342 (26.31%) ── get > │ └───57 (04.38%) ── set > ├────156 (12.00%) ── created [3] > ├────156 (12.00%) ── deleted [3] > └──────0 (00.00%) ── alive On master, after a fresh boot (and added get/set counters): get/set values are very different, we should be able to leverage some speedup if we use readonly/readwrite on indexedDB rather than just readwrite.

With bug 1110063 applied, after booting the device and unlocking the screen: > alex@portable-alex:~/codaz/Mozilla/b2g/devices/Flame/B2G.KK$ grep -c 'READONLY' settings.log > 263 > alex@portable-alex:~/codaz/Mozilla/b2g/devices/Flame/B2G.KK$ grep -c 'READWRITE' settings.log > 154

[Tracking Requested - why for this release]:

Firefox OS is not being worked on