[b2g] 100ms datazilla regression on Jan 31 (Rocketbar)

RESOLVED FIXED in 1.4 S2 (28feb)

Status

Firefox OS
Gaia::Search
P1
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: bkelly, Assigned: kgrandon)

Tracking

({perf, regression})

unspecified
1.4 S2 (28feb)
ARM
Gonk (Firefox OS)
perf, regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [b2gperf_regression][c=progress p= s= u=][systemsfe])

(Reporter)

Description

4 years ago
On Jan 31, 2014 the hamachi devices under test in datazilla were flashed to the next OEM firmware version date Dec 19, 2013.  This caused nearly every app to regress in cold launch times by 100ms.

We saw a launch time in the last OEM firmware upgrade as well.  That was smaller and was attributed to the change to the new fonts in v1.2.

We're not changing major gonk revisions this time, though.  Its unclear what the issue is.

Updated

4 years ago
Component: Gaia → Vendcom
(Hey, sorry for the swath of cc:ed folks, but this needs baseline-establishing before we can reasonably proceed on other branches/devices, I'd think.)
(Reporter)

Comment 2

4 years ago
I may have been to quick to attribute this to the firmware change.  Looking at the pushlog it appears a couple things landed at the same time:

  http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5e0a22097bff&tochange=735a648bca0d
  https://github.com/mozilla-b2g/gaia/compare/6c9fac83b743711d0...f9013a0d20824de7778

Both rocketbar and NUWA landed in this same range.

It also looks like inari regressed by about 100ms at roughly the same time as well.
Component: Vendcom → Gaia
Summary: hamachi OEM 12/19 firmware image caused 100ms datazilla regression → [b2g] 100ms datazilla regression on Jan 31 (OEM firmware 12/9, NUWA, Rocketbar)
(Reporter)

Comment 3

4 years ago
Kevin, could you check to see if disabling rocketbar might fix this cold launch regression with b2gperf?
Flags: needinfo?(kgrandon)
(Reporter)

Comment 4

4 years ago
NUWA has been backed out and the 100ms regression remains.  That suggests to me that NUWA is not to blame here.

Note, however, there was an additional 200+ms regression on Feb 1.  This regression recovered at the same time NUWA was backed out.  Its unclear to me if they were related.  It seems unlikely, though, since NUWA was enabled prior to the original 200+ms change, but I don't see a good alternative explanation in the changelogs.

Here's the ranges for the improvement on Feb 2:

  https://github.com/mozilla-b2g/gaia/compare/3b2fe2f8616...33eb812eadb61
  http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d09f9a9f81ae&tochange=3e40f7389d1b

Its a bit confusing with some many large changes landing and getting backed out in a short period.
(Reporter)

Comment 5

4 years ago
Looking at the video in eideticker (yay eideticker!):

  http://eideticker.mozilla.org/b2g/#/inari/b2g-contacts-startup/timetostableframe

You can see that there is a visual change to draw the app name in the upper left of the status bar now that rocketbar is enabled.  Looking at the frame difference graph before rocketbar:

  http://mzl.la/1bhUtbn

And after rocketbar:

  http://mzl.la/1k0yH43

It is evident that the additional time is occurring around when the current app name in the upper left of the screen is changed.

This would seem to suggest its a rocketbar issue.
(Assignee)

Comment 6

4 years ago
Hey Ben - those eideticker videos are sweet! :)

I may have addressed some of this yesterday with landing of bug 966312. Before we were clearing the title, then setting it.

I may further be able to fix this by delaying the setting of the title, but that may cause some UX impact.
Flags: needinfo?(kgrandon)
(Assignee)

Comment 7

4 years ago
I suppose we're looking at 1.2s vs 1.38s to the "big" pixel jump. 180ms to paint the title seems like an excessively long time to wait. I'm wondering if it could be some issue where we're checking too many event listeners?
(Reporter)

Comment 8

4 years ago
Thanks Kevin!  If you don't mind, I'm going to assign this to you.

Also, it looks like template app is the best app to show this problem on datazilla.  It doesn't seem to be impacted by most of the other commit noise going on right now.
Status: NEW → ASSIGNED
Component: Gaia → Gaia::System
Summary: [b2g] 100ms datazilla regression on Jan 31 (OEM firmware 12/9, NUWA, Rocketbar) → [b2g] 100ms datazilla regression on Jan 31 (Rocketbar)

Updated

4 years ago
Blocks: 946452
blocking-b2g: --- → 1.4?
Component: Gaia::System → Gaia::Search

Updated

4 years ago
Assignee: nobody → kgrandon
Whiteboard: [b2gperf_regression][c=automation p= s= u=] → [b2gperf_regression][c=progress p= s= u=]
Target Milestone: --- → 1.4 S1 (14feb)

Updated

4 years ago
Keywords: perf
Whiteboard: [b2gperf_regression][c=progress p= s= u=] → [b2gperf_regression][c=progress p= s= u=][systemsfe]
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
Rocketbar is being turned off for 1.4, so I'm clearing nom. I filed a separate bug for turning off the feature on 1.4.
blocking-b2g: 1.4? → ---
(In reply to Ben Kelly [:bkelly] from comment #5)
> Looking at the frame difference graph before rocketbar:
> 
>   http://mzl.la/1bhUtbn
> 
> And after rocketbar:
> 
>   http://mzl.la/1k0yH43

I believe bug 966457 has caused these links to become invalid. :(
Target Milestone: 1.4 S2 (28feb) → ---
(Reporter)

Comment 11

4 years ago
So disabling rocketbar has returned us to our previous launch time performance:

  http://mzl.la/1hWhA3M

Disabled in commit:

  https://github.com/mozilla-b2g/gaia/commit/eba290a91ca1a529c48d3145cd4a97d78ed7913c

Closing this as fixed for now.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(In reply to Ben Kelly [:bkelly] from comment #11)
> So disabling rocketbar has returned us to our previous launch time
> performance:
> 
>   http://mzl.la/1hWhA3M
> 
> Disabled in commit:
> 
>  
> https://github.com/mozilla-b2g/gaia/commit/
> eba290a91ca1a529c48d3145cd4a97d78ed7913c
> 
> Closing this as fixed for now.

Note - this bug likely will return when we enable rocketbar on 1.5. Do we want to just open a new bug when that happens or keep this open for tracking?
(Reporter)

Comment 13

4 years ago
Is RocketBar considered completely done or will it be worked on more before being re-enabled?  I had assumed the later and thought making it performant should be part of that work.

Anyway, if we want a bug I would prefer a separate one.
(In reply to Ben Kelly [:bkelly] from comment #13)
> Is RocketBar considered completely done or will it be worked on more before
> being re-enabled?  I had assumed the later and thought making it performant
> should be part of that work.

There's going to be a lot more work on it before it gets enabled again.

> 
> Anyway, if we want a bug I would prefer a separate one.

Fair enough. If we see this problem when rocketbar gets enabled again, then we can open a separate bug.

Updated

4 years ago
Target Milestone: --- → 1.4 S2 (28feb)
You need to log in before you can comment on or make changes to this bug.