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)

ARM
Gonk (Firefox OS)

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
We should come back with acceptance criteria for these startup times.   IMO we're only marginally faster than on Hamachi, so not blocking.
blocking-b2g: 1.3T? → backlog
Going to check manually. NI myself.
Flags: needinfo?(nhirata.bugzilla)
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)
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
clear ni? as it was answered by brogan
Flags: needinfo?(tchung)
blocking-b2g: backlog → ---
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.