Closed
Bug 943594
Opened 11 years ago
Closed 11 years ago
FxOS 1.3 Perf: Cold Launch Regression in Camera, Gallery, Radio, & Video apps
Categories
(Firefox OS Graveyard :: General, defect, P1)
Tracking
(Not tracked)
RESOLVED
WONTFIX
1.3 C1/1.4 S1(20dec)
People
(Reporter: mlee, Assigned: mikeh)
References
()
Details
(Keywords: perf, regression, Whiteboard: [c=progress p= s= u=1.3])
Attachments
(3 files, 2 obsolete files)
Datazilla shows an average 40 - 50ms regression in cold launch times for the Camera, Gallery, Radio, & Video apps in FxOS 1.3 as of today, 2013.11.26. The Usage app also shows a significant spike.
Reporter | ||
Comment 1•11 years ago
|
||
Hema, Datazilla is showing cold launch regressions in the 1.3 codebase for the Camera, Gallery, Radio, & Video apps. Please assign the relevant media engineers to this issue to help identify the root cause. Thanks, Mike
Flags: needinfo?(hkoka)
Comment 2•11 years ago
|
||
We can continue to investigate this while bug 943611 is being worked on. It does not stop investigation of the issue, but is a tool which would allow us to investigate this much faster.
Depends on: 943611
Comment 3•11 years ago
|
||
Mike, On 11/21, I see a dip and then on 11/26 it is spiked up again for camera, gallery and video. Could you take the first shot at investigating what the cause is. Thank you! Hema
Assignee: nobody → mikeh
Flags: needinfo?(hkoka)
Comment 4•11 years ago
|
||
Likely a system change--in the 11/25-26 window, there were no changes to the Camera app or to the camera stack.
Keywords: regressionwindow-wanted
Comment 5•11 years ago
|
||
Worth noting: the datazilla test landed a change within the regression window: https://github.com/davehunt/b2gperf/commits/master/b2gperf/b2gperf.py
Comment 6•11 years ago
|
||
mlee, this bug was filed against v1.3/master/m-c, but I noticed a pretty severe regression in launch-time on v1.2 -- is your team aware of this? Note that during the regression interval, nothing changed in the Camera app or the underlying stack, so this is likely a system problem.
Flags: needinfo?(mlee)
Comment 7•11 years ago
|
||
Looking for candidates in the gaia/master branch, the shared files used by the Camera app haven't changed within the regression window either: locales // 4 months ago shared // 3 minutes ago locales // 3 days ago date.ini // a year ago style // 6 hours ago confirm.css // 6 days ago buttons.css // a month ago confirm.css // 6 days ago js // 6 minutes ago performance_testing_helper.js // 9 months ago l10n.js // a month ago l10n_date.js // 7 months ago async_storage.js // a year ago blobview.js // a month ago gesture_detector.js // 9 months ago lazy_loader.js // a month ago media // 17 days ago
Comment 8•11 years ago
|
||
This spreadsheet includes data for the m-c builds as well. Results are highly variable, particularly in recent builds. - Nov 24: 1679.2ms, 1683.3ms - Nov 25: 1741.7ms - Nov 26: 1733.3ms, 1816.7ms - Nov 27: 1779.2ms, 1704.2ms
Attachment #8339446 -
Attachment is obsolete: true
Reporter | ||
Comment 9•11 years ago
|
||
(In reply to Mike Habicher [:mikeh] from comment #6) > ... > mlee, this bug was filed against v1.3/master/m-c, but I noticed a pretty > severe regression in launch-time on v1.2 -- is your team aware of this? Note > that during the regression interval, nothing changed in the Camera app or > the underlying stack, so this is likely a system problem. MikeH, What severe launch-time regression did you see on 1.2? We're tracking a November 22nd launch-time regression in 1.3 via bug 942893 that appears to be separate this bug 943594 regression impacting media apps. (In reply to Mike Habicher [:mikeh] from comment #5) > Worth noting: the datazilla test landed a change within the regression > window: https://github.com/davehunt/b2gperf/commits/master/b2gperf/b2gperf.py Dave, any comment on whether b2gperf itself may be causing this apparent regression?
Flags: needinfo?(mlee)
Flags: needinfo?(mhabicher)
Flags: needinfo?(dave.hunt)
Comment 10•11 years ago
|
||
(In reply to Mike Lee [:mlee] from comment #9) > (In reply to Mike Habicher [:mikeh] from comment #6) > > ... > > mlee, this bug was filed against v1.3/master/m-c, but I noticed a pretty > > severe regression in launch-time on v1.2 -- is your team aware of this? Note > > that during the regression interval, nothing changed in the Camera app or > > the underlying stack, so this is likely a system problem. > > MikeH, > What severe launch-time regression did you see on 1.2? We're tracking a > November 22nd launch-time regression in 1.3 via bug 942893 that appears to > be separate this bug 943594 regression impacting media apps. Take a look at the v1.2 tab in attachment 8339535 [details]: 175 to 200ms increase in Camera app launch time, despite no changes in the app itself. (I haven't looked at any other apps.) > (In reply to Mike Habicher [:mikeh] from comment #5) > > Worth noting: the datazilla test landed a change within the regression > > window: https://github.com/davehunt/b2gperf/commits/master/b2gperf/b2gperf.py > > Dave, any comment on whether b2gperf itself may be causing this apparent > regression? Dave cleared up the confusion for me earlier today: this change hasn't been released to the infrastructure yet, so it can't be affecting the results. djf, take a look at this chart: https://datazilla.mozilla.org/b2g/?branch=master&device=hamachi&range=7&test=cold_load_time&app_list=camera,gallery,video&app=camera&gaia_rev=6d4c6803d87c3a67&gecko_rev=83587bd621ddfebf A similar dip across Camera, Gallery, and Video apps. Can you think of anything these three apps have in common that would affect them in a way that others such as the Music app are not effected? (Interestingly, the Browser app shows a complementary launch-time chart--I wonder if something changed to improve the Browser launch-time that is affecting a subset of the media apps.)
Flags: needinfo?(mhabicher)
Flags: needinfo?(dflanagan)
Flags: needinfo?(dave.hunt)
Comment 11•11 years ago
|
||
This datazilla chart shows a ~50ms drop in the Camera, Gallery, and Video apps' cold launch times between the Nov 21, 2013, 5:30pm test run (using the 2013-11-20-06-22-58 nightly build) and the 7:40pm test run (using the 2013-11-21-04-04-02 nightly) on the same day: https://datazilla.mozilla.org/b2g/?branch=master&device=hamachi&range=30&test=cold_load_time&app_list=camera,gallery,video&app=camera&gaia_rev=6d4c6803d87c3a67&gecko_rev=83587bd621ddfebf It then shows giving back the 50ms between the Nov 26, 2013, 10:38am test run and the 1:20pm test run. I just tested the 2013-11-20 nightly build with its gaia replaced by the 2013-11-21 version, and observed no significant change in Camera app launch time: 1558ms vs 1554ms. Further confounding matters, I just flashed the 2013-11-21 nightly in its entirety and it shows the same launch time: 1558ms. These results were obtained on Inari, so whatever changed for Hamachi doesn't show up on the other device.
Comment 12•11 years ago
|
||
.:First Broken Build:. Environmental Variables: Device: Buri 1.3 mozRIL BuildID: 20131126052050 Gaia: 4ad796b196d468bdb231beba4392acbc90a74e96 Gecko: 99479edbee2a Version: 28.0a1 Firmware Version: 20131115 .:Last Working Build:. Environmental Variables: Device: Buri 1.3 mozRIL BuildID: 20131125142741 Gaia: bd8053d30c275f8d3040cd494e04b3480a784656 Gecko: 757c2011df5b Version: 28.0a1 Firmware Version: 20131115 The graph was correct about the regression window. 11/26 build was 30-100ms slower than 11/25 across the board for all apps. Oddly enough warm boot times on avg were slower than cold on the 11/26 build. Didn't know that was possible.
Keywords: regressionwindow-wanted
Comment 13•11 years ago
|
||
(In reply to Mike Habicher [:mikeh] from comment #11) > > I just tested the 2013-11-20 nightly build with its gaia replaced by the > 2013-11-21 version, and observed no significant change in Camera app launch > time: 1558ms vs 1554ms. I just corrected an error in my calculations: the 2013-11-20-06-22-58 nightly has a Camera app launch time of 1613ms. The 2013-11-21-04-02-02 nightly has a launch time of 1556ms. This correctly reflects the chart linked to in comment 11. The hybrid test run with the 2013-11-20 nightly gecko and 2013-11-21 nightly gaia shows the faster time, so the speed improvement is due to a change in gaia. On the subsequent nightlies, I measure: - 2013-11-22: 1563ms - 2013-11-23: 1704ms - 2013-11-24: 1679, 1683ms - 2013-11-25: 1741ms - 2013-11-26-04-02-01: 1733, 1829ms - 2013-11-26-05-20-50: 1817ms - 2013-11-27: 1779, 1704ms Results are somewhat variable, but there is definitely a trend towards longer launch times over this period.
Comment 14•11 years ago
|
||
More data, from Nov 20 to Nov 29. Next step--look for any nightlies where this is a big change, and try the gecko from the "before" nightly in combination with gaia from the "after" nightly.
Attachment #8339535 -
Attachment is obsolete: true
Comment 15•11 years ago
|
||
(In reply to Mike Habicher [:mikeh] from comment #10) > A similar dip across Camera, Gallery, and Video apps. Can you think of > anything these three apps have in common that would affect them in a way > that others such as the Music app are not effected? (Interestingly, the > Browser app shows a complementary launch-time chart--I wonder if something > changed to improve the Browser launch-time that is affecting a subset of the > media apps.) No, I can't think of anything that changed. If it was Music instead of Camera, I'd blame mediadb or device storage. But with camera in there, I don't know. And the fact that increase in startup time almost exactly mirrors a decrease from the week before makes me think that this was some system thing that landed, broke stuff, and got backed out. Hasn't there been a lot of churn in the graphics layer?
Flags: needinfo?(dflanagan)
Comment 16•11 years ago
|
||
When I look at a datazilla graph like this, I don't see a startup time regression. I see a promising startup time improvement that got backed out.
Comment 17•11 years ago
|
||
That's the conclusion I'm coming to as well: there are certainly no shortage of visual changes over the anti-regression interval, and towards the end, things mostly go back to the way they were. Removing blocking-1.3 nom.
blocking-b2g: 1.3? → ---
Comment 18•11 years ago
|
||
FYI, I'm currently investigating if bug 942483 is due to a gonk firmware change around this time frame. That might also explain the changes with these apps. Unfortunately I may not be able to prove it conclusively since we don't collect enough information at datazilla currently. (We opened bug 946254 to help fix that.)
Comment 19•11 years ago
|
||
And by bug 942483 in comment 18 I actually meant bug 942893.
Comment 20•11 years ago
|
||
I was able to reproduce the regression running the b2gperf Gallery launch test on my buri: gaia git ed5b8ba7245f, gecko hg 53d55d2d0a25 - median 445ms gaia git 6d4c6803d87c, gecko hg 99479edbee2a - median 492ms This seems unrelated to bug 942893 and follows the gecko rev. I bisected it to this: changeset: 157467:33f136f3274b user: Benoit Girard <b56girard@gmail.com> date: Mon Nov 25 15:12:20 2013 -0500 summary: Backout 08eaaed722ef for regression bug 942788. This was a backout of bug 917416. Since this is a legitimate backout I'm going to mark this WONTFIX.
Reporter | ||
Updated•10 years ago
|
Target Milestone: --- → 1.3 C1/1.4 S1(20dec)
You need to log in
before you can comment on or make changes to this bug.
Description
•