Closed Bug 857398 Opened 8 years ago Closed 7 years ago

[Call log] Call log list takes too long to load when item count > 500

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:leo+)

RESOLVED FIXED
1.1 QE1 (5may)
blocking-b2g leo+

People

(Reporter: leo.bugzilla.gaia, Assigned: alberto.pastor)

References

Details

(Keywords: perf, Whiteboard: c= s=2013.05.31 , [TD-11585] [QE1])

Attachments

(1 file)

1.80 MB, video/mp4
Details
1. Title : Call log list takes too long to load when item count > 500
2. Precondition : Existing list more 500 items in Call log
3. Tester's Action : Enter call log
4. Detailed Symptom : Takes too long to load
5. Expected : 
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia revision :
Attached video video(mp4)
blocking-b2g: --- → leo?
This seems like a dup of bug 847399
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 847399
blocking-b2g: leo? → -
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Change some conditions

------

4. Detailed Symptom : Dialer app takes 18.9 seconds(3 times average), however it should be 1.5 seconds according to leo device spec.
5. Expected : Dialer app takes under 1.5 seconds
This is still a duplicated of bug 847399. Any reason why you want to keep this bug open?
Because change conditions.

FFOS has to pass leo device performance test, and it needs Comment 3 conditions.
But "bug 847399" cannot satisfy this conditions, so I keep this bug open.
blocking-b2g: - → leo?
Whiteboard: [TD-11585]
I agree -- bug 847399 is a meta bug without real performance targets so we can't block on that, but this one now contains the real target we need to achieve (comment #3).
Whiteboard: [TD-11585] → [TD-11585] [QE1]
Target Milestone: --- → Leo QE1 (5may)
Kevin - since you have a lot of experience lazily loading these lists, how much work do you think this would be? Please set back to leo? if this ends up being too much work, so that we can discuss with our partner.
Assignee: nobody → kgrandon
blocking-b2g: leo? → leo+
(In reply to Dylan Oliver [:doliver] from comment #6)
> I agree -- bug 847399 is a meta bug without real performance targets so we
> can't block on that, but this one now contains the real target we need to
> achieve (comment #3).

There is already work being done in bugs 847406 and 848027 to achieve the real target that you mention. I cannot see the point of duplicating this work...

If I am not wrong, Gregor Wagner has already been testing the performance improvements of the solution proposed in these bugs so he might be able to confirm that we are within the expected target.

(In reply to leo.bugzilla.gaia from comment #5)

> FFOS has to pass leo device performance test, and it needs Comment 3
> conditions.
> But "bug 847399" cannot satisfy this conditions, so I keep this bug open.

Then nominate its dependencies to leo?
Flags: needinfo?(anygregor)
I've just nominated bug 847404, bug 848027 and bug 847406 for leo?
I tested Borjas patch from bug 847406 and it's a huge improvement. The first calls are shown right away.
My only concern is that we load the whole list of calls before we access the contacts API to show actual names. I talked to Borja and filed bug 847406. It should be an easy fix according to Borja.

We should also limit the number of entries in the call log. AFAIK we don't do this. Maybe limit it to N entries or the last N months. Keeping all entries around will become a performance problem no matter what
Flags: needinfo?(anygregor)
Thanks Gregor!

(In reply to Gregor Wagner [:gwagner] from comment #10)
> My only concern is that we load the whole list of calls before we access the
> contacts API to show actual names. I talked to Borja and filed bug 847406.
> It should be an easy fix according to Borja.
> 

The call log DB already has a limit param for the getters, so yes, it should be pretty easy to fix.

> We should also limit the number of entries in the call log. AFAIK we don't
> do this. Maybe limit it to N entries or the last N months. Keeping all
> entries around will become a performance problem no matter what

There is already a discussion about that in Bug 829399. Feel free to reopen it.
As we already have a meta bug for dialer performance, it seems that we can mark this as a duplicate of bug 847399.
Depends on: 861905
Depends on: 853632
Priority: -- → P1
Depends on: 865079
Assignee: kgrandon → alberto.pastor
Whiteboard: [TD-11585] [QE1] → c= [TD-11585] [QE1]
Duplicate of this bug: 869972
(In reply to Kevin Grandon :kgrandon from comment #12)
> As we already have a meta bug for dialer performance, it seems that we can
> mark this as a duplicate of bug 847399.

given thats a meta bug, this shouldnt be a dupe of it.  instead, i'll roll it up under the dependency tree.

fwiw, i can reproduce the slowness.  i timed that it took around 15 secs as i watched the call log slowly populate data in the UI.  as a user, this is unacceptable if i wanted to tap a previous number and quickly dial back.

tested against 1.0.1 Inari nightly build.
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/b0b2b5cfdc5b
Gaia   30ad443fbe5363a7381c19c6bf9d6ca49228fb8b
BuildID 20130509070209
Version 18.0
Blocks: 847399
Tony, that slowness should be fixed (mitigated, at least) by Bug 847406, already landed in master.
We would like to have some QA on that before uplifting it. Would it be possible making a quick QA review of the call log in master before the uplift? Thanks.
Flags: needinfo?(tchung)
adding qawanted, even though i'll try and get to this.
Flags: needinfo?(tchung)
Keywords: qawanted
bug 847406 is landed on master and v1-train following a QA pass from Naoki. Can we resolve this issue now?
Flags: needinfo?(alberto.pastor)
I would love to land Bug 847409 first, but it's not mandatory. If partners are happy with current performance (I think is acceptable) we can resolve this bug. Another option is just resolving it and verify/reopen it depending if current performance is enough or not. Both options work for me.
Flags: needinfo?(alberto.pastor)
(In reply to Alberto Pastor [:albertopq] from comment #18)
> Another option is just resolving it and verify/reopen it depending
> if current performance is enough or not. 

Let's take this route if you believe the current code can meet the expectation in comment #3. That doesn't have to prevent us from continuing improvements in bug 847409 in master and requesting uplift when that is ready.
Flags: needinfo?(alberto.pastor)
It definitively meets the expectation of 1.5sec for making the call log usable with > 500. It doesn't mean the whole list will be fully loaded in 1.5 sec, though.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Flags: needinfo?(alberto.pastor)
Resolution: --- → FIXED
Sounds like the original QA request was solved in https://bugzilla.mozilla.org/show_bug.cgi?id=847406#c32.
Keywords: qawanted
Keywords: perf
Whiteboard: c= [TD-11585] [QE1] → c= s=2013.05.31 , [TD-11585] [QE1]
is there anything that needs to land on branches for this?
(In reply to John Ford [:jhford] -- please use 'needinfo?' instead of a CC from comment #22)
> is there anything that needs to land on branches for this?

On my unagi device an initial search still takes up to 10s until the results are displayed. So I also wonder what is missing on b2g18.
(In reply to John Ford [:jhford] -- please use 'needinfo?' instead of a CC from comment #22)
> is there anything that needs to land on branches for this?

AFAIK there is nothing left to uplift


(In reply to Henrik Skupin (:whimboo) from comment #23)
> (In reply to John Ford [:jhford] -- please use 'needinfo?' instead of a CC
> from comment #22)
> > is there anything that needs to land on branches for this?
> 
> On my unagi device an initial search still takes up to 10s until the results
> are displayed. So I also wonder what is missing on b2g18.

How are you testing it?

Note that the first time that you open the call log after pushing a reference workload the database needs to be upgraded and needs to do the data migration. So that could take some extra time. Consecutive executions should go faster though. Also, note that the maximum amount of logs in a normal situation is below 250 after bug 829399 landed.

With Gaia master + Gecko birch I am getting the first bunch of call logs almost instantly.
Oh sorry, I mixed-up the bug with bug 865747. So the call log is working fine for me, and responds immediately.
You need to log in before you can comment on or make changes to this bug.