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

Status: RESOLVED FIXED

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

Description

[Leo]

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 :

Comment 1

[Leo]

Attachment: video(mp4)

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

This seems like a dup of bug 847399

Comment 3

[Leo]

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

Comment 4

[Fernando Jiménez Moreno [:ferjm]]

This is still a duplicated of bug 847399. Any reason why you want to keep this bug open?

Comment 5

[Leo]

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.

Comment 6

[Dylan Oliver [:doliver]]

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

Comment 7

[Alex Keybl [:akeybl]]

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.

Comment 8

[Fernando Jiménez Moreno [:ferjm]]

(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?

Comment 9

[Fernando Jiménez Moreno [:ferjm]]

I've just nominated bug 847404, bug 848027 and bug 847406 for leo?

Comment 10

[Gregor Wagner [:gwagner]]

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

Comment 11

[Fernando Jiménez Moreno [:ferjm]]

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.

Comment 12

[Kevin Grandon :kgrandon]

As we already have a meta bug for dialer performance, it seems that we can mark this as a duplicate of bug 847399.

Comment 14

[Tony Chung [:tchung]]

(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

Comment 15

[alberto.pastor]

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.

Comment 16

[Tony Chung [:tchung]]

adding qawanted, even though i'll try and get to this.

Comment 17

[Dylan Oliver [:doliver]]

bug 847406 is landed on master and v1-train following a QA pass from Naoki. Can we resolve this issue now?

Comment 18

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

Comment 19

[Dylan Oliver [:doliver]]

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

Comment 20

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

Comment 21

[Jason Smith [:jsmith]]

Sounds like the original QA request was solved in https://bugzilla.mozilla.org/show_bug.cgi?id=847406#c32.

Comment 22

[John Ford [:jhford] CET/CEST Berlin Time]

is there anything that needs to land on branches for this?

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 24

[Fernando Jiménez Moreno [:ferjm]]

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

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Oh sorry, I mixed-up the bug with bug 865747. So the call log is working fine for me, and responds immediately.