Closed Bug 848316 Opened 11 years ago Closed 11 years ago

Contacts startup spends more than 1sec requesting "orderBy" preference before get contacts

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Contacts
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: alberto.pastor, Unassigned)

References

Details

We need to know "orderBy" preference before requesting contacts to mozContacts. Right now, that boolean is stored in indexedDB, but it takes 1.2sec to load it.  

I know localStorage is evil, but we save more than 1sec storing that boolean there instead.

Should we workaround the indexedDB slowness with localStorage in contacts?
1.2sec for a boolean is insane.
Do you use your own indexedDB or the settingsDB?
We are using contacts own indexedDB, not settings. We were told that preference wasn't supposed to be a common setting. Worth trying workaround using settingsDB as well...
I would prefer this perf problem is fixed globally in indexedDB or asyncStorage as multiple apps probably are suffering the same problem. going back to localStorage does not seem to be a good solution.
Where is the time being spent in the 1.2s?

+1 on using asyncStorage. I think we should have fatal crash triggered on localStorage use by certified applications, since people continue think it's ok. It's never ok.
Blocking a blocker -> blocking+.
blocking-b2g: --- → tef+
bent and me debugged this problem yesterday.
This is not an indexedDB problem but rather a contacts app / main thread problem.
We found that we send the request to the parent and return value back to the child in about 50 msec.
The problem is now in the child. It takes around 700msec to receive the value in the child. Once we receive the value, we dispatch it to the main thread and it takes another 400 msec until we call the success callback. So 700 + 400 is around 1.1 sec until we call the callback.

So the child process has a busy main thread that never returns to the event loop. We found that basically we send the "orderby" request and right afterwards we start executing the contacts.init function in JS that loads a big chunk of facebook init and localization code and doesn't return to the event loop for about 500 msec. Right afterwards we start rendering (profiler shows css work) that takes another few hundred msec.

Going forward we have two ways to improve the situation:
1) We try to eliminate the need to wait for the event loop twice in the child. So right after we receive the result from the parent we should call the success callback. This is a one line change in the code but it shows some assertions during tests and bent is looking at it.
2) The contacts app should return to the event loop more often and shouldn't occupy the main thread for such a long time. Or even better, don't load everything during startup. I don't have any facebook contacts on my phone but still all the code is loaded during startup.
note that fixing the 1) issue from the previous comment won't actually make the contacts app start any sooner. We would still be blocked by the Facebook and styling work that is happening. I.e. fixing the issue in 1) will just change the order of the work, it won't reduce any of the work that we do.

So I would say we should file new bugs on the Facebook initialization and the styling and start addressing those.
And probably mark this bug as INVALID because we aren't actually spending the 1 second spin the request. We are spending it doing other things.
The link to the profile:
http://people.mozilla.com/~bgirard/cleopatra/#report=271bef7575d5361a53c6ac1a055e63f68791892d

The interesting part it between 1610 and 3145.
Around 1610 we send the request and at 3145 we call the success callback in JS.
Any updates here from the gaia side? Do we want to change the way the contacts app works?
Flags: needinfo?(alberto.pastor)
I filed bug 849943 on investigating whether we can remove the extra dispatch for indexedDB. It may not be possible given the way the IPC code works today, but in any case even if we fixed that we'd still have the problems outlined in comment 7.
Hey all, what's the next steps for this bug?
The problem is requesting that value while painting. Requesting it before everything, will delay the startup time, so I'm trying to do it after painting, and it "only" takes 300ms. I still think is too much for a boolean. For the record, we only load 1 Facebook file (for knowing if it's enabled) until the contacts list is loaded. The files laszy loaded are not related to Facebook.
I will try to create a patch to optimize the code, returning back to the event loop more often and trying to load that value when the CPU is free. Can we use a cookie if that's faster than 300ms?
Flags: needinfo?(alberto.pastor)
Depends on: 849943
Depends on: 851741
No longer depends on: 851741
I'm going to mark this invalid since we're not actually spending 1 second loading the data from IDB. We're spending 1 second doing a lot of other things.

Please file separate bugs on improving the other aspects as needed and mark those as blocking bug 846895.

Morphing bugs is always a bad idea.
Status: NEW → RESOLVED
blocking-b2g: tef+ → ---
Closed: 11 years ago
Depends on: 851741
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.