1095034 - Too much IndexedDB on startup

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Performance, defect, P2)

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: log.txt

Comment 2

[Julien Wajsberg [:julienw]]

Cc Bevis for the SMS part

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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?

Comment 4

[[:fabrice] Fabrice Desré]

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.

Comment 5

[Bevis Tseng[:bevis][:btseng](Exited)]

(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

Comment 6

[Julien Wajsberg [:julienw]]

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.

Comment 7

[:gerard-majax]

(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

Comment 8

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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

Comment 9

[:gerard-majax]

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

Comment 10

[:gerard-majax]

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

Comment 11

[:gerard-majax]

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.

Comment 12

[:gerard-majax]

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

Comment 13

[:gerard-majax]

> 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.

Comment 14

[:gerard-majax]

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

Comment 15

[Bobby Chien]

[Tracking Requested - why for this release]:

Comment 16

[BMO Automation]

Firefox OS is not being worked on