865741 - [meta] Use caching for lists

Status: RESOLVED WONTFIX

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

Description

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Some lists are growing quite fast and are hard to use when they reach around 500 entries. Caching the lists data can help drastically. I suggest to implement this for call log, contacts and sms since this is the 3 lists where this is the most noticeable.

I consider this a blocker since those parts of the phone are unusable for me after 1 intensive month of usage.

Not blocking on this means the phone will be unusable after a few months of use for all users...

Comment 1

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I have added a poc in bug 865747 that shows how much it can help.

Comment 2

[alberto.pastor]

Hi there,
I already did a poc for caching (and already synchronising with contacts changes), but after lasts improvements in the Backend I didn't feel it was needed anymore. In the Frontend side, we had a performance review in Madrid, and the only small point to be fixed was the "renderOrg" method, that obviously is too expensive for what it does.

Could you please upload a video or give more details about STR (number of contacts, contact to be accessed, and times), as I'm not having those problems with my 500 contacts dogfooding agenda. 

Regarding the code, where can I find cache.js and visibility_monitor? Is important knowing how long do we spend retrieving the cache. At the other hand, are we sure retreiving the whole cache is not more expensive for showing the first chunk, that doing it with cursors?

Thanks for the poc! Let me reproduce your use case and see how we can solve it.

Regards

Comment 3

[alberto.pastor]

Ups, this comment was meant to be at bug 865747 

(In reply to Alberto Pastor [:albertopq] from comment #2)
> Hi there,
> I already did a poc for caching (and already synchronising with contacts
> changes), but after lasts improvements in the Backend I didn't feel it was
> needed anymore. In the Frontend side, we had a performance review in Madrid,
> and the only small point to be fixed was the "renderOrg" method, that
> obviously is too expensive for what it does.
> 
> Could you please upload a video or give more details about STR (number of
> contacts, contact to be accessed, and times), as I'm not having those
> problems with my 500 contacts dogfooding agenda. 
> 
> Regarding the code, where can I find cache.js and visibility_monitor? Is
> important knowing how long do we spend retrieving the cache. At the other
> hand, are we sure retreiving the whole cache is not more expensive for
> showing the first chunk, that doing it with cursors?
> 
> Thanks for the poc! Let me reproduce your use case and see how we can solve
> it.
> 
> Regards

Comment 4

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Alberto Pastor [:albertopq] from comment #3)
> Ups, this comment was meant to be at bug 865747 
> 
> (In reply to Alberto Pastor [:albertopq] from comment #2)
> > Hi there,
> > I already did a poc for caching (and already synchronising with contacts
> > changes), but after lasts improvements in the Backend I didn't feel it was
> > needed anymore. In the Frontend side, we had a performance review in Madrid,
> > and the only small point to be fixed was the "renderOrg" method, that
> > obviously is too expensive for what it does.
> > 
> > Could you please upload a video or give more details about STR (number of
> > contacts, contact to be accessed, and times), as I'm not having those
> > problems with my 500 contacts dogfooding agenda. 
> > 
> > Regarding the code, where can I find cache.js and visibility_monitor? Is
> > important knowing how long do we spend retrieving the cache. At the other
> > hand, are we sure retreiving the whole cache is not more expensive for
> > showing the first chunk, that doing it with cursors?
> > 
> > Thanks for the poc! Let me reproduce your use case and see how we can solve
> > it.
> > 
> > Regards

I replied there :)

Comment 5

[Alex Keybl [:akeybl]]

Blocks blockers

Comment 6

[Dylan Oliver [:doliver]]

Updating the email dependency chain.

Comment 7

[Jon Hylands [:jhylands]]

I'm not sure why this blocks bug 863988 or bug 857398, which both appear to be more or less resolved independently.

Comment 8

[Mike Lee [:mlee]]

Vivien,

Is this bug meant to be a meta/parent bug for tracking all related (blocked) issues or is there work that needs to be done specifically for this one?

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Michael Lee [:mlee] from comment #8)
> Vivien,
> 
> Is this bug meant to be a meta/parent bug for tracking all related (blocked)
> issues or is there work that needs to be done specifically for this one?

It means to be a meta.

Comment 10

[Mike Lee [:mlee]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #9)
> 
> It means to be a meta.

Thanks Vivien. Unassigning from Jon since there's nothing for him to do here.

Comment 11

[Jan Jongboom [:janjongboom] (inactive)]

FYI, http://sergimansilla.com/blog/virtual-scrolling/

Comment 12

[Julien Wajsberg [:julienw]]

WHat sadden me here is that it doesn't use the Visibility Monitor that we already have.

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

Should this still be leo+ now that bug 857398 has been resolved?  I don't see any other leo+ bugs in the blocked list.

I ask because its been suggested that DataStore is the long term caching solution.  However, if DataStore cannot be uplifted to b2g18, then it seems we may need some short term solution.

And if so, does this short term solution really need to be general like this meta bug suggests, or can we handle the critical issues on a case-by-case basis?

Comment 14

[Ben Kelly [:bkelly, not reviewing]]

Dietrich recommended I set this to leo? based on my thoughts in comment 13.

Comment 15

[Kevin Grandon :kgrandon]

Depending on bug 940428 for now. I believe we want to try out a streaming cursor based approach, which should make it unnecessary to use caching.

Comment 16

[BMO Automation]

Firefox OS is not being worked on