842217 - Contacts list swipe and pan gets stuck because of frequent GCs

Status: VERIFIED FIXED

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

Description

[Michael Vines [:m1] [:evilmachines]]

STR:
1) Launch contacts with some contacts (50 in my case)
2) Swipe around a little
3) Frequently a swipe will take ~500ms to be recognized. 

Panning suffers from the same problem.

Comment 1

[alberto.pastor]

Hi Michael. Could you confirm if that happens only while the list is loading? Could you upload a video otherwise?

Thanks!

Comment 2

[Michael Vines [:m1] [:evilmachines]]

No, it happens after list is fully loaded.  About 50 contacts in my case.

Comment 3

[alberto.pastor]

Sorry about this question, but could you please clarify what do you mean by swipe and panning? As I understand swipe, is dragging the list, and I can't see any delay on that once the list is loaded... In that case can you upload a video?

Thanks

Comment 4

[Michael Vines [:m1] [:evilmachines]]

Hey Alberto,
I loaded the latest from v1.0.1 today and I can no longer reproduce the 'delayed swipe'.  If I can trigger it again I'll share a video.

So what remains in this bug is just the sluggish contacts list panning FPS.   Maybe this is covered in another bug?   STR:
1) Pan the contacts list up/down quickly. 

Observe it update at ~30 FPS.   I see ~40FPS if the contacts I'm panning have no associated images.

Comment 5

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

I loaded 200 contacts in contact list. And tried to scroll contact list. 

Result of obsevation:
1)    Contact scrolling is showing 1 sec stutters sometimes. UI HomeScreen App's (image_loader.js) onscroll() Javascript function takes 1 sec to display image using (image_loader.js) LoadImage() Javascript function. This is difficult to reproduce.

2)    Contact scrolling is causing too much time in rendering. PressShell:Paint () is running but TryRender function is not running. It also takes different times for rendering for different frames. in some cases ,  PressShell:Paint () is called 3 times consecutively (~45ms) but there was no real updates in display. So contact scrolles is not smooth. 

duration of PressShell::Paint() Varies from ~15ms to ~31ms.

Comment 6

[Michael Vines [:m1] [:evilmachines]]

Maybe dup of 835742 at this point...

Comment 7

[alberto.pastor]

I don't think is a dup. That patch only makes the first contacts load faster (so it would decrease that 1sec stutters on observation 1 to almost half of it).

I'm not sure what's happening on observation 2... May be css ellipisis forcing repaints when scroll bar appears? Just a blind guess...

Thanks for the info, just write here if you guys investigate further. I'll take a look tomorrow.

Comment 8

[Andrew Overholt [:overholt]]

QA, we could really use a reliable STR here so we can catch this during profiling.

Comment 9

[Gregor Wagner [:gwagner]]

Most (not all) of the times I see a pause during swiping we are GCing. 
Sometimes I see many GC invocations:
http://www.pastebin.mozilla.org/2165139
Bill, any idea how this could happen?

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I believe that this is a duplicate of bug 835742.

Details on why:
I tried on 1.0.1 on today's build: with 500+ contacts, slowness in panning occurs within the first couple of minutes.  I believe because even though it looks fully loading, it's still loading blobs.  (images of the contacts and other information).  This is with facebook imported contacts.

I tried on the master w/ today's build due to  bug 842983 and Bug 835742 landing on master.  Contact scrolling does appear to be faster ie no panning performance issue; having said that imports from facebook nor SIM is working as expected : bug 843835 and Bug 843833

Comment 11

[Gregor Wagner [:gwagner]]

Lets keep this bug open.

We found that we perform multiple GCs and that's caused by our logic that tries to minimize heap growth.
If we fix our GC triggers, we see less GCs but the duration of an individual GC increases to 300+ msec.

Comment 12

[Gregor Wagner [:gwagner]]

Attachment: WiP

Comment 13

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Is the garbage created by the contacts app necessary or is it creating unnecessary objects?

Comment 14

[Gregor Wagner [:gwagner]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #13)
> Is the garbage created by the contacts app necessary or is it creating
> unnecessary objects?

My theory is that it's not garbage created by the contacts app. I think these are touch points/events that don't get added to any GC trigger. Once we trigger a GC we spend a lot of time sweeping objects but the GC heap is not bigger than 4-6MB. If I test with the patch in bug 844313 we trigger more GCs because of memory allocations outside of the gc heap.

Comment 15

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Important issue to fix in relatively prime real estate.

Comment 16

[Dietrich Ayala (:dietrich)]

Would take if patch available, but not holding 1.1 back for this fix without more information about just how severe it is.

Comment 17

[Andreas Gal :gal]

Gregor has a good theory here. He will have a patch soon.

Comment 18

[Gregor Wagner [:gwagner]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6de0da52f3a3

Comment 19

[Dietrich Ayala (:dietrich)]

Does this actually depend on bug 842804 and bug 844313? This landed but those are still open.

Comment 20

[Gregor Wagner [:gwagner]]

(In reply to Dietrich Ayala (:dietrich) from comment #19)
> Does this actually depend on bug 842804 and bug 844313? This landed but
> those are still open.

The main bug should be fixed with this patch.
Bug 844313 handles a corner case that can result in the same behavior (pause time during swiping). The corner case is swiping for a long time without navigating. Like swiping the contacts list for a few minutes without actually clicking on anything.
We create a ton of touch events that don't modify any GC trigger. So once we trigger a GC, finalizing all the touch events can take up to half a second. The idea in bug 844313 is to trigger more GCs if we only create events.

Comment 21

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/6de0da52f3a3

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/2c005ac46747
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/04e7ef49da0c

Comment 23

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I figured out why I wasn't able to reproduce the behavior Gregor was seeing. It's because we don't trigger GCs until gcBytes hits 3MB (on b2g). The highest I could ever get it to go was 1MB. So I guess the problem with high/low-freq GCs was only an issue if the app was using more than 3MB of GC heap. That's probably why it wasn't caught earlier. (I'm still not sure how Gregor managed to use more than 3MB of heap in the contacts app.)

The GCs I *do* get are based on the GC_IDLE_FULL_SPAN timer.

Comment 24

[Jeni]

Verified fixed on 
Unagi Build ID: 20130329070203
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/56c922308fd1
Gaia: 0a9f78bffafda93a159c1f502e8b110c2f49a500

and

Unagi Build ID: 20130329070203
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/5cc5df16447a
Gaia: 26b463f14caa11e0fc64fda09a17054da4bea68b