Closed Bug 1090810 Opened 10 years ago Closed 10 years ago

[Stingray] add SettingsCache to smart system

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: johnhu, Assigned: johnhu)

References

Details

(Whiteboard: [ft:conndevices])

Attachments

(1 file)

Smart system queries lots settings. And each of them may cost ~500ms. If the amount of queries exceed 8, we may use SettingsCache to do it. Experiments on mozSettings are needed.
Blocks: 1090775
No longer depends on: 1090775
Hi Rex,

I had changed all reading from mozSetting to read from SettingsCache. Please review this patch. For the benchmark number, please find the doc here:
https://docs.google.com/a/mozilla.com/spreadsheets/d/19BPa6GCxPPoLZxy_r1tJSPG4JZVUCbpSKwSXYjJ5Jbg/edit?usp=sharing

you may need to login as mozilla account to open it.
Attachment #8514040 - Flags: review?(rexboy)
Comment on attachment 8514040 [details] [review]
use settingscache to improve device boot time

The code looks mostly good to me with some comments. Please see Github before landing.

Have we already opened a bug for putting local storage together with SettingsCache? If yes, please set dependency from to this bug.

Thanks for your work!
Attachment #8514040 - Flags: review?(rexboy) → review+
We don't have that bug. And it is async storage instead of local storage. I am not sure it is a correct way to improve the boot up time. We need to discuss more about this before filing issue and create the PR.

Anyway, thanks for your review. I will revise the PR with all of your concerns before landing it.
rebased and merged to master:
https://github.com/mozilla-b2g/gaia/commit/b54f50d195232f6022bf140686b9daacda40d291
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
When you say 500ms, can you detail more ? It seems way much more that what we see on phones.
Flags: needinfo?(im)
Alexandre,

I use new Date().getTime() at the timing we query the mozSettings and dump the elapsed time at callback. I did not keep the testing patch.

But the experimental result is at comment 1. The same result was observed by partner. You may re-test it with the latest master.
Flags: needinfo?(im)
Alexandre, I think 500ms is for the whole settings get process:

console.time('check');
mozSettings.createLock().get().onsuccess = () => console.timeEnd('check');
(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #7)
> Alexandre,
> 
> I use new Date().getTime() at the timing we query the mozSettings and dump
> the elapsed time at callback. I did not keep the testing patch.
> 
> But the experimental result is at comment 1. The same result was observed by
> partner. You may re-test it with the latest master.

John, thanks, but figures without any explanations of what you measured precisely are useless. Given your comment and Julien's, I think I get a better overview of the 500ms your are hitting.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: