1073009 - [kk base] Regression in contacts startup 2014-09-16

Status: RESOLVED DUPLICATE of bug 1069452

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

Description

[Francisco Jordano [:arcturus] [:francisco]]

+++ This bug was initially created as a clone of Bug #1059860 +++

We can see a regression in contacts startup happening around the 16th of September:

https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=30&test=cold_load_time&app_list=contacts&app=contacts&gaia_rev=caf6d0b58cdf62c9&gecko_rev=4c80ec2e0d49&plot=avg

Comment 1

[Francisco Jordano [:arcturus] [:francisco]]

Attachment: kk-16sept-c21106017e7def8a436ec807a9fda746de5504ca.json

Performance test for latest working version.

Time is around 1000ms for visually complete event.

Comment 2

[Francisco Jordano [:arcturus] [:francisco]]

Attachment: kk-16sept-1503e1f9f7846a3813c057ce95c35ac22031027f.json

Commit causing regression in contacts, about 100 ms, with average 1100ms (extra 100ms).

This measures have been steady since we landed bug 1071722, there we gain around 40-50 ms, but that bug is not related to this patch.

Comment 3

[Francisco Jordano [:arcturus] [:francisco]]

I've noticed that the offending commit:

https://github.com/mozilla-b2g/gaia/commit/1503e1f9f7846a3813c057ce95c35ac22031027f

from bug 1044125, was uplifted to branch 2.1 on the 19th of September.

If we take a look to datazilla the 19th of September we could appreciate how the performance in branch 2.1 also get's affected:

https://datazilla.mozilla.org/b2g/?branch=v2.1&device=flame-319MB&range=30&test=cold_load_time&app_list=contacts&app=contacts&gaia_rev=caf6d0b58cdf62c9&gecko_rev=4c80ec2e0d49&plot=avg

Comment 4

[Francisco Jordano [:arcturus] [:francisco]]

Attachment: master-reverted.json

This is a perf test from master, backing out the offending contact, where we go to an average startup time of 976 ms.

Comment 5

[Francisco Jordano [:arcturus] [:francisco]]

Commit

https://github.com/mozilla-b2g/gaia/commit/1503e1f9f7846a3813c057ce95c35ac22031027f

it's happening in the system app, pinging Aus and Etienne for trying to get some info here.

Also realised in datazilla, that we can see the same increase in startup load time for *some* apps in the same date:

https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=30&test=cold_load_time&app_list=browser,clock,contacts,usage&app=contacts&gaia_rev=caf6d0b58cdf62c9&gecko_rev=4c80ec2e0d49&plot=avg

but other apps are unaffected.

Comment 6

[Aus Lacroix [:aus]]

It's possible that we're no longer preventing _setVisible from being called multiple times. Before we essentially ended up with a guard against this by checking screenshotOverlayState in setVisible, showFrame and hideFrame. I think it would be possible to add similar checks back in based on checking frame visibility.

We do have checks to make sure we don't re-request the screenshot so that shouldn't be the cause of this regression.

I could whip up a quick patch later today to see if we can go back to our original perf numbers.

Comment 7

[Aus Lacroix [:aus]]

Chatting with Eli about this and we think this is a very likely dupe of bug 1064952. Definitely fits into the regression window. Let's all move our discussion to that bug. :)

Comment 8

[Robert Strong (they/them - no direct email)]

(In reply to Ghislain Aus Lacroix [:aus] from comment #7)
> Chatting with Eli about this and we think this is a very likely dupe of bug
> 1064952. Definitely fits into the regression window. Let's all move our
> discussion to that bug. :)
> 
> *** This bug has been marked as a duplicate of bug 1064952 ***
bug 1064952 has only landed on oak so that isn't possible

Comment 9

[Aus Lacroix [:aus]]

Ugh, sorry guys, had a dyslexic moment! bug 1069452 is the one I was actually referring to.