major firstPaint regression (up to 40%) and raise in variance

RESOLVED FIXED in B2G C3 (12dec-1jan)

Status

Firefox OS
Gaia
P1
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: gandalf, Assigned: vingtetun)

Tracking

({perf, regression})

unspecified
B2G C3 (12dec-1jan)
ARM
Gonk (Firefox OS)
perf, regression

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Today's builds are showing massive variance and average regression in firstPaint up to 40%.

Trying to find a window
(Reporter)

Comment 1

5 years ago
it's also less responsive to touch events (sometimes selecting different region)
(Reporter)

Comment 2

5 years ago
bisected.

That's commit https://github.com/mozilla-b2g/gaia/commit/ecf5e0d963c51db269ed43be450245fa2051d6e8

Bug 820267

Impact tested on Unagi vs. Gecko 18

firstPaint, avg of 5 cold boots:

           || 63fa5a2 || ecf5e0d ||    %
===========||=========||=========||=========
Homescreen ||  5200   ||  5294   ||  +1.8%
Settings   ||  1508   ||  2390   ||  +58%
Dialer     ||  1745   ||  3616   ||  +107%
SMS        ||  1647   ||  2590   ||  +57%
Email      ||  5048   ||  8202   ||  +62%
Calendar   ||  2231   ||  2984   ||  +33%
Contacts   ||  1865   ||  2435   ||  +30%


stddev:

           || 63fa5a2 || ecf5e0d ||    %
===========||=========||=========||=========
Homescreen ||  665    ||  704    ||   +5%
Settings   ||   22    ||  804    ||   +3554%
Dialer     ||  106    ||  1628   ||   +1435%
SMS        ||   23    ||  453    ||   +1869%
Email      ||   28    ||  325    ||   +1060%
Calendar   ||   39    ||  548    ||   +1305%
Contacts   ||  355    ||  752    ||   +111%
Yuren, we need to back this change out until we know what's wrong.  We can't regress startup this much.

Maybe we're accidentally leaving the animation running again?
Assignee: nobody → yurenju
blocking-basecamp: --- → +
Keywords: perf, regression
OS: Mac OS X → Gonk (Firefox OS)
Priority: -- → P1
Hardware: x86 → ARM
Blocks: 820267
Target Milestone: --- → B2G C3 (12dec-1jan)
I have made some little changes to the lockscreen in order to not suffer this regression. See https://github.com/vingtetun/gaia/commit/d2e7bdaafd270802db7ad3769a5e627dd7b94e3e
Created attachment 693960 [details] [diff] [review]
Patch
Assignee: yurenju → 21
Attachment #693960 - Flags: review?(kaze)
Comment on attachment 693960 [details] [diff] [review]
Patch

Review of attachment 693960 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, and the code is much more readable now (at least for me!). Thanks for this work.
Attachment #693960 - Flags: review?(kaze) → review+
What were the changes?  With a build before the backout, I see intermittent high CPU usage on the homescreen, as if the animation continues running when not visible (like it did before).
(In reply to Chris Jones [:cjones] [:warhammer] from comment #7)
> What were the changes?  With a build before the backout, I see intermittent
> high CPU usage on the homescreen, as if the animation continues running when
> not visible (like it did before).

As you said the animation was running in the background since it was launched again via a setInterval when the main panel of the lockscreen was unloaded.

https://github.com/mozilla-b2g/gaia/commit/4e92bbce55a05e61242d46f55228c0dd2e462843
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
\o/
You need to log in before you can comment on or make changes to this bug.