Firefox OS/Performance/Roadmap

From MozillaWiki
Jump to: navigation, search

This wikipage is in progress. This page lists roadmap items for improving Performance on Firefox OS devices. Partner specific information is not listed here.


Getting performance improvements can be split up into three steps:

  • Measure
  • Automate
  • Drive to Goals

This page lists information on current state and plans to get the best performing device in the world.

Metric fxOS 2.0 fxOS 2.1 fxOS 2.2 fxOS 2.3 TBD Goal Current state (July '14) Drive to goals
App First Launch + Relaunch Publish Results for first launch time for Core Apps(bug ) Publish Results for relaunch time for Core Apps bug 1043657 Publish first launch for third party apps bug to_be_filed_future
  • No Regressions from previous release
  • App first launch < 1.0 second
  • First launch time < or equal to competitive OSs
  • Eideticker (Camera) tracking of first launch Eideticker
  • Datazilla (instrumentation events) tracking of first launch at | Datazilla
    • enhancements will be done with bug 996038 planned for 2.0
  • Tracking bugs proactively, bisecting solution.
  • Track regressions across releases bug 1043798
    • Near release dates (eg: for 6 weeks before FC) focus on regressions between releases (1.3 versus 2.0) in addition to daily regressions
  • Making sure GAIA teams are engaged
    • brown bag
    • weekly email showing performance comparison versus goals.
  • Publish memory usage on system and per app basis bug 1044297
  • No regressions in memory used by each app and overall system. Any increase due to new feature increase must be justified.
  • After loading on 256Mbytes device, should have 80 Mbytes free for apps to run
  • Support the lowest mem device to use the particular version of release.
  • Lowest use of Memory among smartphones OS.
  • Filing bugs for any regressions
  • For 4 weeks before FC, focus on macro differences (eg: 1.3 versus 2.0)
Graphics: Uniformity, Jank, Scroll, FPS Reducing jank and smoothening FPS. (Project Silk on B2G:bug 987532)
  • Tracking uniformity/jank, and scroll fps for Core apps bug 990833
  • Goal:
    • High frame uniformity (in a input of constant finger scroll, displacement of frame per unit time should constant): deviation of < +-5 pixels is goal
    • Friction: Discussion with UX on what the friction value should be (1042017)
    • Checkerboarding/low res tiling:
      • % of white space should be < x% for a scroll speed of with scroll finger movement by Z%.
  • Equal to or better than Competitive OSs

Power Consumption Publish power consumption results to datazilla
  • Publishing power consumption to Datazilla
  • Tracking ril, video, idle
  • Battery life last 24 hours for heavy usage
  • should be less than or equal to competitive OSs
  • Ril, video, idle are first to track
Get app teams and QA to take ownership? (brown bag?)
Responsiveness Phase 1 of bug 989590 filed bug bug_to_be filed bug 989590 Common micro-interactions perceived as responsive. Need more detailed definition ?
MTBF 100 hours
Browser Benchmarks Competitive with Chrome browser on Android

App first launch + relaunch



Memory Leaks

Uniformity, Graphics, Jank, FPS


Frame per second is the frequency at which unique images are produced. Uniformity of Scroll frames per second is important aspect of user experience. 60 fps is the standard expected for cellular phones for scrolling.


MTBF is average of time between failures. This is computed by taking N observations of device running till failure, and average these observations


This defn is valid whether one or multiple devices is used.

In the special case when TBF observation that is still running and did not yet fail. assume the device(s) fails in the next sec, and add that TBF to numerator and increase denominator by 1.


Browser Benchmarks


Google Docs