Closed
Bug 994296
Opened 10 years ago
Closed 9 years ago
[Tarako] [Usage] cold start time averages 1151 ms, while other apps hover around 750ms
Categories
(Firefox OS Graveyard :: Performance, defect, P2)
Tracking
(tracking-b2g:backlog)
RESOLVED
WONTFIX
tracking-b2g | backlog |
People
(Reporter: tchung, Unassigned)
References
Details
(Keywords: perf, Whiteboard: [c=progress p= s= u=tarako])
the cold start time on the Usage App for Tarako averages about 1151ms. To compare: * Other core apps are around 750ms on Tarako * Usage App cold start averages around 950ms on Hamachi Measured on April 9th, 2014. We dont have historical data for this device to determine if this is a regression or not. So this bug in question is to determine if this criteria is acceptable or not. See: https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=30&test=cold_load_time&app_list=browser,calendar,camera,clock,contacts,gallery,phone,settings,template,usage,video&app=usage&gaia_rev=62acb4b0e774b670&gecko_rev=5f74965cfe60&plot=avg
Comment 1•10 years ago
|
||
We should come back with acceptance criteria for these startup times. IMO we're only marginally faster than on Hamachi, so not blocking.
Updated•10 years ago
|
blocking-b2g: 1.3T? → backlog
Going to check manually. NI myself.
Flags: needinfo?(nhirata.bugzilla)
Comment 3•10 years ago
|
||
Tony + Naoki, What numbers do you see when using the on-device Developer HUD's "Time to load" setting? All, FxOS Responsiveness Performance Goals are: 0 - 140ms: App's icon shows that it's been touched. 0 - 1.00s: App's launch animation started and completed. 0 - 1.00s: App's core interface (e.g. banner and controls) must be loaded and visible. 0 - 1.00s: App's above-the-fold (visible) content or a "Loading..." message must be displayed. 0 - 1.25s: App's ready for user interaction (e.g. touch, scroll, etc.) The above times are cumulative so app icon touch to app interaction-ready is expected to occur within 1.25s. We've created a Responsiveness Performance wiki page[1] and will post goals there. Linked from that page is a spreadsheet[2] we (Gordon UX) has put together mapping the Taipei team's Tarako Performance Results to our Responsiveness goals. 1: https://wiki.mozilla.org/B2G/Performance/Responsiveness 2: http://bit.ly/1sDmepL
Severity: critical → major
Flags: needinfo?(tchung)
Priority: -- → P2
Whiteboard: [c=progress p= s= u=tarako]
I think it depends on if you are looking at having set up the Usage app versus going through the FTU for Usage. The FTU seems to take longer than cold boot: FTU cold boot: http://www.youtube.com/watch?v=GrethHziaLo&feature=youtube_gdata_player Usage cold boot: http://www.youtube.com/watch?v=Wob5apsAHrE&feature=youtube_gdata_player I think the performance criteria have been meet for the Usage app.
Flags: needinfo?(nhirata.bugzilla)
Comment 5•10 years ago
|
||
Issue still occurs on latest 1.3T. Unable to see much difference between Cost Control FTU and normal Cost Control cold boot. Times taken for first paint with Time to Load enabled. Rebooted between each attempt. Usage FTU - 1647ms; 1283ms; 2039ms Usage Cold - 1675ms; 1323ms; 1644ms 1.3T Environmental Variables: Device: Tarako 1.3T BuildID: 20140418014001 Gaia: f0872318d46781bb59d0a13a2e1fffb115b8ca2b Gecko: 32bb713e6d0d Version: 28.1 Firmware Version: sp6821a_gonk4.0_user.pac
Assignee | ||
Updated•9 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Updated•9 years ago
|
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•