MozillaWiki - User contributions [en]

Firefox OS/Performance/Boot Timing Automation

2014-09-26T21:58:12Z

Mlee: /* Plan Outline */ More links to actual implementation.

As per [https://bugzilla.mozilla.org/show_bug.cgi?id=1045938 Bug 1045938], the plan for implementing automated boot info capturing will be described below. The end goal is the eventual creation of a system to support the continued tracking of the status of boot performance. That is to say, one should be able to simply do something like
<pre>
make test-perf boottest
</pre>
and receive the appropriate data. Furthermore we would like to get this information into datazilla along with all the other performance numbers we track.

===Plan Outline===
This primarily relates to {{bug|1047118}}.
The simplest approach we could take for accomplishing this is as follows:

The data emitted for each stage will be:
# Capture and store pre-gecko timing to disk (something like <code>"/data/local/.BOOTTIMES.json"</code>)
#* See {{bug|1058810}} and {{bug|1058811}} for implementation.
#* Currently setting an android property in init, and accessing it from b2g.sh to write out to disk
#* Also capturing the timing of when we launch b2g proper
#* File in JSON format to be compatible with the other tools.
# settings.js/shell.js generate a time stamp (that is stored in some standard property of the window) near its entrypoint.
#* See {{bug|1058817}} and [https://bugzilla.mozilla.org/attachment.cgi?id=8479247&action=diff#a/b2g/chrome/content/settings.js_sec2 this changeset] for proposed implementation.

# System app (in chrome) records timing at some decided location (as in the prior step):
#* Do this right before iframe creation in shell.js ?
#* See {{bug|1058817}} and [https://bugzilla.mozilla.org/attachment.cgi?id=8479247&action=diff#a/b2g/chrome/content/shell.js_sec2 this changeset] for proposed implementation.

# System App:
#* Record time stamp at entry point, like previously.
#* See implementation [https://github.com/mozilla-b2g/gaia/pull/23521/files#diff-0 here] and [https://github.com/mozilla-b2g/gaia/pull/23521/files#diff-1 here].

# Vertical homescreen
#* Record time stamp at entry point
#* See implementation [https://github.com/mozilla-b2g/gaia/pull/23521/files#diff-2 here].
#* moz-* are emitted

#* There is no way of actually observing these events for homescreen currently implemented, and there needs to be work done to make use of these events being fired in this test framework.

<code>make test-perf</code> will consume the <code>.BOOTTIMES.json</code> file, and all the properties to give back meaningful data. See {{bug|1058843}} and [https://github.com/mozilla-b2g/gaia/pull/23521/files#diff-4 this changeset] for the boot test's implementation.

In the pre-gecko timing one of the data points will be a pair of both "uptime" and "epoch time". Using this, we can calculate the time of boot in terms of epoch time, which is more compatible with times we have access to in the higher levels of the stack. If there were ever to be some WebAPI to get device uptime, this would be a far preferable means, and would very much minimize the complexity currently needed in this implementation.


.

Another problematic portion of the implementation is that as a result of the system date taking time to correct itself upon boot (sometimes this is even after gecko has started), depending on when one samples the date, it is possible to get a very incorrect date. As a stop gap measure, I collect a time "early" in the boot sequence, and another "late" in the boot sequence, and for the calculations use which ever is more appropriate as the reference.

In the current design of <code>make test-perf</code>'s startup_event_tests, the test designates code to be injected, and launches the app, thus having full control over the whole process. This is not quite a suitable approach for the system and verticalhome apps which are kind of special cases. Upon gecko finishing its initialization steps, shell.html is unconditionally loaded, which loads the system app directly (which then also goes and prepares the lockscreen and the homescreen). The approach of injecting certain handlers may be possible however, if one reloads b2g to give the code a chance to be injected into the relevant frames.

What the boot_test does is, instead of firing and catching events, it (in the future perhaps conditionally upon a setting) records time stamps in some predetermined object for the test harness to collect afterwards. This way there is minimal impact on the app's performance. The test looks for results in the system chrome, the system app, and the homescreen.








===Data Visualization===
Once the data itself is collected it could be presented in datazilla. What this would look like would be for there to be a Boot test, and for each stage in the boot process to have its own line tracked over time. The Y-axis would be the cumulative time from boot, of each stage. This allows one to easily see how the duration of each section changes over time. Some parts (like the kernel) would likely stay relatively static, while we may see more fluctuations in others (gaia or gecko for example).

Firefox OS/Performance/Boot Timing Automation

2014-09-26T21:47:05Z

Mlee: /* Plan Outline */ More links to actual implementation.

As per [https://bugzilla.mozilla.org/show_bug.cgi?id=1045938 Bug 1045938], the plan for implementing automated boot info capturing will be described below. The end goal is the eventual creation of a system to support the continued tracking of the status of boot performance. That is to say, one should be able to simply do something like
<pre>
make test-perf boottest
</pre>
and receive the appropriate data. Furthermore we would like to get this information into datazilla along with all the other performance numbers we track.

===Plan Outline===
This primarily relates to {{bug|1047118}}.
The simplest approach we could take for accomplishing this is as follows:

The data emitted for each stage will be:
# Capture and store pre-gecko timing to disk (something like <code>"/data/local/.BOOTTIMES.json"</code>)
#* See {{bug|1058810}} and {{bug|1058811}} for implementation.
#* Currently setting an android property in init, and accessing it from b2g.sh to write out to disk
#* Also capturing the timing of when we launch b2g proper
#* File in JSON format to be compatible with the other tools.
# settings.js/shell.js generate a time stamp (that is stored in some standard property of the window) near its entrypoint. 

# System app (in chrome) records timing at some decided location (as in the prior step):
#* Do this right before iframe creation in shell.js ?

# System App:
#* Record time stamp at entry point, like previously.
#* See implementation [https://github.com/mozilla-b2g/gaia/pull/23521/files#diff-0 here] and [https://github.com/mozilla-b2g/gaia/pull/23521/files#diff-1 here].

# Vertical homescreen
#* Record time stamp at entry point
#* See implementation [https://github.com/mozilla-b2g/gaia/pull/23521/files#diff-2 here].
#* moz-* are emitted

#* There is no way of actually observing these events for homescreen currently implemented, and there needs to be work done to make use of these events being fired in this test framework.

<code>make test-perf</code> will consume the <code>.BOOTTIMES.json</code> file, and all the properties to give back meaningful data. See {{bug|1058843}} and [https://github.com/mozilla-b2g/gaia/pull/23521/files#diff-4 this changeset] for the boot test's implementation.

In the pre-gecko timing one of the data points will be a pair of both "uptime" and "epoch time". Using this, we can calculate the time of boot in terms of epoch time, which is more compatible with times we have access to in the higher levels of the stack. If there were ever to be some WebAPI to get device uptime, this would be a far preferable means, and would very much minimize the complexity currently needed in this implementation.


.

Another problematic portion of the implementation is that as a result of the system date taking time to correct itself upon boot (sometimes this is even after gecko has started), depending on when one samples the date, it is possible to get a very incorrect date. As a stop gap measure, I collect a time "early" in the boot sequence, and another "late" in the boot sequence, and for the calculations use which ever is more appropriate as the reference.

In the current design of <code>make test-perf</code>'s startup_event_tests, the test designates code to be injected, and launches the app, thus having full control over the whole process. This is not quite a suitable approach for the system and verticalhome apps which are kind of special cases. Upon gecko finishing its initialization steps, shell.html is unconditionally loaded, which loads the system app directly (which then also goes and prepares the lockscreen and the homescreen). The approach of injecting certain handlers may be possible however, if one reloads b2g to give the code a chance to be injected into the relevant frames.

What the boot_test does is, instead of firing and catching events, it (in the future perhaps conditionally upon a setting) records time stamps in some predetermined object for the test harness to collect afterwards. This way there is minimal impact on the app's performance. The test looks for results in the system chrome, the system app, and the homescreen.








===Data Visualization===
Once the data itself is collected it could be presented in datazilla. What this would look like would be for there to be a Boot test, and for each stage in the boot process to have its own line tracked over time. The Y-axis would be the cumulative time from boot, of each stage. This allows one to easily see how the duration of each section changes over time. Some parts (like the kernel) would likely stay relatively static, while we may see more fluctuations in others (gaia or gecko for example).

Firefox OS/Performance/Boot Sequence Optimization

2014-09-26T21:36:24Z

Mlee: /* The Plan */ Added link to Boot Timing Automation

==Initial Ideas==
* Minimize data loaded by boot loader.
** Compacting vmlinuz/zImage by moving compiled-in drivers to modules.
** Minimize initial ramdisk if there is one.
** Minimize kernel cruft by excluding all unneeded drivers.
** Strip the kernel and all modules.
* Minimize init launch sequence.
** Make init only launch the bare minimum for b2g process to launch.
** Ideally, init will '''only''' launch b2g.
* B2G start-up sequence.
** Remove all synchronous external dependencies from B2G start-up sequence.
*** Kernel modules must be lazy loaded as needed.
*** Any sync waits on daemons must become async. Start-up b2g pieces as daemons finish launching.
*** Minimize start-up initializations.
**** Global statics need to be minimized as their constructors are run before main().
**** Global singletons must be initialized as needed.
* Homescreen start-up.
** Minimize _init() code to bare minimum.
** Maybe freeze the homescreen app into a memory image that can be loaded and unfrozen instead of launching the app every time.
** Eliminate dependency on enumerating installed apps on launch.
*** Cache the list in local storage?
*** Cache the list in the frozen memory image?
*** Speed up mgmt.getAll()

==The Plan==
* [[FirefoxOS/Performance/Boot_Profiling|Boot Profiling]]
* [[FirefoxOS/Performance/Boot_Timing_Automation|Boot Timing Automation]]

==Bootchart==
[http://www.bootchart.org/ Bootchart] is a tool for collecting data on OS boot, and then processing it into easily digestible charts. Some example preliminary data collected via bootchart [http://people.mozilla.org/~jbailey/fxos_bootchart/ here].

To enable the collection of bootchart data in FireFox OS one must build '''init''' with the following environment variable set.
<pre>
INIT_BOOTCHART=true
</pre>

Once init on the device has been replaced with the bootchart-enabled version [[FirefoxOS/Performance/Modifying boot.img|(see process here)]], to begin logging one simply creates a file <code>|/data/bootchart-start|</code> on the device containing an integer representing the number of seconds for which bootchart should collect data, and then reboots the device.

Bootchart data is pulled from the device with the <code>system/core/grab-bootchart.sh</code> script, and presented in the form of a bootchart.tgz file. With the data collected one can then generate graphs by invoking:
<pre>
java -jar bootchart.jar -f eps bootchart.tgz
</pre>

Without the <code>|-f eps|</code> parameters, the default is for a PNG to be generated. The SVG format is also supported.

Note that the charts generated by the stock bootchart.jar do not seem to include disk stats. This is because it does not recognize the <code>mmcblk'''N'''p'''M'''</code> format of disk partition names, and this can easily be fixed in the bootchart source code (in particular, in <code>|bootchart-0.9/src/org/bootchart/parser/linux/ProcDiskStatParser.java|</code>).

Another bootchart related change made was in regards to how it records collected data. By default the process name is discarded and replaced by the 'cmdline' invocation (found in proc/PID/cmdline). This is not very useful considering b2g apps are then all shown as "Plugin-container". Init was [http://people.mozilla.org/~jbailey/bchart.patch modified] such that both names are recorded.

=== Data ===
Data collected is organized as follows:
<pre>
repo-state -> Information about the state of the source tree that applies to this experiment.
Note that things such as changes in init.rc, kernel arguments would not be visible in this

manifest.xml -> Repository info auto-generated by repo. This can be used with repo to reset the tree
(not including changes to the working tree)

experi-info -> Information about this particular experiment

N/ -> Each of the numbered directories represent one sample of data

N/bootchart.N.tgz -> Bootchart archive encapsulating the data that was collected

N/kmsg.N -> A dump of the kernel logs of the device
Contains timestamp for when init has started, and time stamp for when b2g.sh is run by init
(and misc. other component initialization)

N/logcat.N -> A dump of the android logs of the device
Contains timestamp of when b2g has started (which is also useful to synchronize with kernel log times)
(since logcat logs time absolutely, and kmsg as an offset from startup

N/rebootstamp.N -> Local unix time recorded directly after an adb reboot to approximate time of boot

N/synchstamp.N -> Kernel logs are time since boot and so are the process start times, this file contains the local time and the current device
uptime so that one may determine when the kernel logs were initialized
</pre>

[http://people.mozilla.org/~jbailey/v10G-first-baselines/ Old Baseline statistics]
These results were collected but I then decided to base my experiments on the newer v121 baseimage.

Note that all data collected applies to the Flame reference device.

[http://people.mozilla.org/~jbailey/v121-2-baseline/ Baseline statistics]

This is data collected for the purposes of establishing a baseline.
For this and future data collection, at least 30 trials will be recorded. Also in the root directory there are a few randomly selected trials for which charts were generated for quick reference.

A rough idea of what was seen, as well as empirical hypotheses:
* B2G starts after roughly 8s of mysterious "stuff", impenetrable to bootchart
* Based on kmsg, it is likely that time between 5s and 8s is init script execution up until <code>|class_start main|</code> in the init.rc (which launches B2G service)
* Vertical is shown as coming up around 16s, however it is actually just the preallocated process at this point, which later becomes vertical (around 22s-23s).
* As well it seems we are only at the init entry point around 4 seconds in anyway (based on inserted kernel log output)

* As such it is likely that
<code>
** -3.5s = bootloader + Early kernel
**    0s = kernel timing initialized
** ~4.5s = init main
**  7-8s = B2G
**  ~14s = (Nuwa)
**  ~16s = Preallocated
**  ~22s = Homescreen app?
**  ~25s = UI presented to user
</code>

Of note is that there exists a pronounced black screen between the T2mobile and the "Mozilla Developer Network" logos, that was introduced at some point. Dave Huseby has noted in the past that such a noticeable black screen exists in other devices. This was less visible in past versions.

Of course, there is more concrete data, but that is the general trend of things.

[http://people.mozilla.org/~jbailey/v121-2-premainb2g/ Experiment #1]

In this simple experiment a change to "init.rc" was made. By default b2g was started along with a host of other services in the same class "main". For this experiment B2G was moved into its own class that was started just before main. As expected this did not have significant effect in when B2G was launched however, since these were all launched in fairly quick order. Quantitatively one does notice a difference in the bootchart images reflecting B2G being started slightly earlier.

[[File:baseline-bootchart.16.png|top|800px|Baseline, B2G is launched along with other services]]
[[File:premainb2g-bootchart.16.png|top|800px|Launch B2G just prior to other services in main]]

In these images, each horizontal bar represents the lifetime of a process. A processes children are below it, and parent child relationships are indicated by a dotted line from the parent going into the beginning of the child's bar. The process bars are in order of launch time (earliest first). Blue segments of the bar represent CPU activity while pink segments indicate IO.

Based on the current code, the earliest it is conceivably possible to run B2G would be in the early-init stage of init.rc. This stage was observed to be executing at around 4.8s of uptime. Realistically a lot of things would need to be changed for this to work (that is to say, a lot of things break when this is attempted). A more logical stage would be early-boot (which is not used in the default init script, however is a supported stage that occurs between post-fs-data and boot). What is notable about this stage is that, A.) if done here, B2G launches at around 5.8s and B.) It successfully runs. Sometimes. There are clearly some dependencies that are not quite guaranteed to be ready if one attempts to launch B2G this early, which could be the subject of a future investigation to see if those dependencies could be moved earlier as well. However as it stands, this only launches B2G around 2 seconds earlier. and there actually was no decrease in overall boot time observed (again dependencies not being respected comes to mind as an explanation, or gaia/gecko depending on some other service being initialized).

[http://people.mozilla.org/~jbailey/v121-2-lesswreckless/ Related Data]. Fewer trials were done because these were just cursory feasibility tests.
One will note that in the first 13 trials B2G tries to launch, crashes, and then relaunches at around 12s, whereas it starts fine for the last 3. Seen below is a sample of a run in which B2G crashes vs. not

[[File:lesswl-bootchart.12.png|top|800px|Crashing]]
[[File:lesswl-bootchart.13.png|top|800px|Not Crashing]]

In particular one can search for the string OPTBOOT in the kmsg.N and logcat.N files for a look at the timings of a few important points.

<pre>
in kmsg:
|OPTBOOT: INIT START|
represents (close to) the entry point of init's main

in both:
|OPTBOOT: Starting B2G|
represents the b2g service being started. This is also shared with logcat, since this time is
also used to synchronize with the logcat log which is only reported in terms of absolute time.
This is needed since once one gets high enough in the application layer
it becomes very difficult to message the kernel logs.

in logcat:
|Content JS LOG at app://verticalhome.gaiamobile.org/js/app_manager.js:126 in anonymous: OPTBOOT: Vertical: app_manager.js:126|
A message from javascript-land. In particular near the entry point for the Vertical Homescreen application.
It should be noted that this occurs around a second or so before things are put on the screen.
</pre>

In the trials for which b2g survives, if one calculates the offset from boot of the Vertical home screen log message, one sees that it is about 24s as opposed to 26s in the trials it crashes.

==References==
[https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Firefox OS Bootup Procedure]

Firefox OS/Performance/Boot Timing Automation

2014-09-26T21:33:02Z

Mlee: Added links to bugs for relevant pieces of implemenation

As per [https://bugzilla.mozilla.org/show_bug.cgi?id=1045938 Bug 1045938], the plan for implementing automated boot info capturing will be described below. The end goal is the eventual creation of a system to support the continued tracking of the status of boot performance. That is to say, one should be able to simply do something like
<pre>
make test-perf boottest
</pre>
and receive the appropriate data. Furthermore we would like to get this information into datazilla along with all the other performance numbers we track.

===Plan Outline===
This primarily relates to {{bug|1047118}}.
The simplest approach we could take for accomplishing this is as follows:

The data emitted for each stage will be:
# Capture and store pre-gecko timing to disk (something like <code>"/data/local/.BOOTTIMES.json"</code>)
#* See {{bug|1058810}} and {{bug|1058811}} for implementation.
#* Currently setting an android property in init, and accessing it from b2g.sh to write out to disk
#* Also capturing the timing of when we launch b2g proper
#* File in JSON format to be compatible with the other tools.
# settings.js/shell.js generate a time stamp (that is stored in some standard property of the window) near its entrypoint. 

# System app (in chrome) records timing at some decided location (as in the prior step):
#* Do this right before iframe creation in shell.js ?

# System App:
#* Record time stamp at entry point, like previously.

# Vertical homescreen
#* Record time stamp at entry point
#* moz-* are emitted

#* There is no way of actually observing these events for homescreen currently implemented, and there needs to be work done to make use of these events being fired in this test framework.

<code>make test-perf</code> will consume the <code>.BOOTTIMES.json</code> file, and all the properties to give back meaningful data. See {{bug|1058843}} for the boot test's implementation.

In the pre-gecko timing one of the data points will be a pair of both "uptime" and "epoch time". Using this, we can calculate the time of boot in terms of epoch time, which is more compatible with times we have access to in the higher levels of the stack. If there were ever to be some WebAPI to get device uptime, this would be a far preferable means, and would very much minimize the complexity currently needed in this implementation.


.

Another problematic portion of the implementation is that as a result of the system date taking time to correct itself upon boot (sometimes this is even after gecko has started), depending on when one samples the date, it is possible to get a very incorrect date. As a stop gap measure, I collect a time "early" in the boot sequence, and another "late" in the boot sequence, and for the calculations use which ever is more appropriate as the reference.

In the current design of <code>make test-perf</code>'s startup_event_tests, the test designates code to be injected, and launches the app, thus having full control over the whole process. This is not quite a suitable approach for the system and verticalhome apps which are kind of special cases. Upon gecko finishing its initialization steps, shell.html is unconditionally loaded, which loads the system app directly (which then also goes and prepares the lockscreen and the homescreen). The approach of injecting certain handlers may be possible however, if one reloads b2g to give the code a chance to be injected into the relevant frames.

What the boot_test does is, instead of firing and catching events, it (in the future perhaps conditionally upon a setting) records time stamps in some predetermined object for the test harness to collect afterwards. This way there is minimal impact on the app's performance. The test looks for results in the system chrome, the system app, and the homescreen.








===Data Visualization===
Once the data itself is collected it could be presented in datazilla. What this would look like would be for there to be a Boot test, and for each stage in the boot process to have its own line tracked over time. The Y-axis would be the cumulative time from boot, of each stage. This allows one to easily see how the duration of each section changes over time. Some parts (like the kernel) would likely stay relatively static, while we may see more fluctuations in others (gaia or gecko for example).

Firefox OS/Performance

2014-08-15T18:56:14Z

Mlee: Removed reference to fxos-perf@mozilla.com email address.

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The team members and contact points below no longer handle these responsibilities on a daily basis.'''''</big>

{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Wander Costa, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee + Jean Gong
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Meetings=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The meetings and activities below will no longer occur.'''''</big>
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]''' -:- '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q1 Taipei: 2014.03.31 - 04.04]''' -:- '''[https://fxos-perf.etherpad.mozilla.org/workweek2013q3 Toronto: 2013.08.26 - 29]'''
|-
|}

=Areas=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The fxOS Performance Areas below are no longer led nor maintained by the listed individuals.'''''</big>
{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation|Automation]]''' || Hubert Figuière & Geo Mealer
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' || Wander Costa
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=== Regression Duty ===
Current areas of regression duty:
* Watch b2gperf start up times https://datazilla.mozilla.org/b2g
* Watch fxos-pert alerts. Currently, limited in scope to start up time regressions.
* Map of Gecko revisions reported by datazilla to their correct revision https://people.mozilla.org/~asasaki/vcs2vcs/gecko-dev/gecko-mapfile
* Get access to Jenkins. File a bug like [https://bugzilla.mozilla.org/show_bug.cgi?id=1036477 bug 1036477]

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]
* [http://charts.mozilla.org/ffos/blockers.html#responsibility=FxOS_Team&project=1.3,1.3T,1.4,2.0 Release Blocking Dashboard]

=Plans=
* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap Doc]
* [https://wiki.mozilla.org/FirefoxOS/Performance/Roadmap Roadmap Wiki (in progress)]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]
** [http://datazilla.readthedocs.org/en/latest/webservice/ Datazilla Web Service Documentation]
*** Use /b2g/testdata/raw endpoint to retrieve data, revision == gaia revision. ([https://datazilla.mozilla.org/b2g/testdata/raw/master/43e6b5fa9482809a425286b3cbf429f803585084 example])

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance/Tools

2014-08-15T17:27:08Z

Mlee: /* References */ Added link to perf tool blog post.

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=devtools",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

==Dashboards==
* [[../Datazilla|Using Datazilla]]
* [http://wrla.ch/blog/2013/05/proof-of-concept-eideticker-dashboard-for-firefoxos/ Using Eideticker]
** [http://wrla.ch/blog/2014/03/its-all-about-the-entropy/ Measuring Entropy]

==Handling Regressions==
* [[../Bisecting_Regressions|Bisecting]]
* [http://blargon7.com/2014/03/hunting-for-performance-regressions-in-firefox-os/ Root-Causing]
* '''Reverting'''
** update tree
** git revert -m1 originalCommitHash. ''-m1 is only needed if the original commit was a merge.''
** git push

==Instrumentation==
* [[../Automation_Testing|Automation & Testing]]
* [[/Data_Sources_and_Tools_for_FxOS_Perfomance_Optimization|Data Sources & Tools for FxOS Performance Optimization]]

==Profiling==
* [https://developer.mozilla.org/en-US/Apps/Developing/Performance/Performance_fundamentals/Power?redirectlocale=en-US&redirectslug=Mozilla%2FFirefox_OS%2FPerformance%2FPower Power]
* [[../Profiling|Speed]]
* [[../Memory|Memory]]
** [[Performance/MemShrink|MemShrink]]
** [[Memory_Reporting|Reporting]]
** [http://bit.ly/membuster Stress Testing]
* '''Mock Data'''
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Gaia/Hacking_Tips_And_FAQ#Reference_Workloads Reference Workloads (via Gaia build targets)]
** [https://github.com/mozilla/b2gpopulate B2G Populate (via Automation Team)]
* [https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Debugging_B2G_using_valgrind Valgrind]

==References==
* [http://blog.linuxprogrammer.org/Hacking%20B2G%3A%20Building%20with%20Distcc.html Building FirefoxOS with Distcc]
* [http://rhaas.blogspot.co.uk/2012/06/perf-good-bad-ugly.html perf: the good, the bad, the ugly]
* [[Remote_Debugging_Protocol|Remote Debugging Protocol]]
* [http://rilanalyzer.smart-e.org/ RILAnalyzer]

Firefox OS/Performance/Power

2014-08-15T17:24:14Z

Mlee: /* References */ Added link to GreenMining blog post.

This page is used to track Firefox OS' power usage tracking and improvement efforts.

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=power",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

== Testing ==
* [[B2G/Performance/Power Testing|Process & Goals]]
** [[B2G/Performance/Sample Delay Calibration of COTS Ammeter|Sample Delay Calibration of COTS Ammeter]]
* Baselines
** [https://mana.mozilla.org/wiki/display/~dhuseby@mozilla.com/FxOS+Power+Consumption+Data First Run]
* [[B2G/Power_Consumption|Power Consumption Measurements (old)]]

== Hardware ==
* [https://wiki.mozilla.org/B2G/Performance/AmmeterRequirements Ammeter Requirements]
* [https://wiki.mozilla.org/B2G/BatteryHarnessCosting Battery Harness Costs]
* [http://people.mozilla.org/~jhylands/harness_setup/ Battery Harness Setup]
* [https://fxos-perf.etherpad.mozilla.org/12 Battery Harness - Signups]
** Please edit the above etherpad to add yourself or your team if you need a battery harness

== References ==
* [https://developer.mozilla.org/en-US/Apps/Developing/Performance/Performance_fundamentals/Power MDN: FxOS Power Measurement]
* [https://fxos-perf.etherpad.mozilla.org/perf-testing-integration Power Planning]
* [http://ravitillo.wordpress.com/2014/01/21/a-matter-of-energy/ A Matter of Energy]
* [http://softwareprocess.es/static/GreenMining.html GreenMining: The Effect of Software Change on Power Consumption]
* [http://ravitillo.wordpress.com/2014/02/04/idle-wakeups-are-evil/ Idle Wakeups are Evil]

Firefox OS/Performance

2014-08-14T22:29:32Z

Mlee: /* Meetings */ Added links to Taipei and Toronto Workweek etherpads.

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The team members and contact points below no longer handle these responsibilities on a daily basis.'''''</big>

{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Wander Costa, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee + Jean Gong
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org, '''[mailto:fxos-perf@mozilla.com fxos-perf@mozilla.com]'''
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Meetings=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The meetings and activities below will no longer occur.'''''</big>
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]''' -:- '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q1 Taipei: 2014.03.31 - 04.04]''' -:- '''[https://fxos-perf.etherpad.mozilla.org/workweek2013q3 Toronto: 2013.08.26 - 29]'''
|-
|}

=Areas=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The fxOS Performance Areas below are no longer led nor maintained by the listed individuals.'''''</big>
{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation|Automation]]''' || Hubert Figuière & Geo Mealer
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' || Wander Costa
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=== Regression Duty ===
Current areas of regression duty:
* Watch b2gperf start up times https://datazilla.mozilla.org/b2g
* Watch fxos-pert alerts. Currently, limited in scope to start up time regressions.
* Map of Gecko revisions reported by datazilla to their correct revision https://people.mozilla.org/~asasaki/vcs2vcs/gecko-dev/gecko-mapfile
* Get access to Jenkins. File a bug like [https://bugzilla.mozilla.org/show_bug.cgi?id=1036477 bug 1036477]

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]
* [http://charts.mozilla.org/ffos/blockers.html#responsibility=FxOS_Team&project=1.3,1.3T,1.4,2.0 Release Blocking Dashboard]

=Plans=
* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap Doc]
* [https://wiki.mozilla.org/FirefoxOS/Performance/Roadmap Roadmap Wiki (in progress)]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]
** [http://datazilla.readthedocs.org/en/latest/webservice/ Datazilla Web Service Documentation]
*** Use /b2g/testdata/raw endpoint to retrieve data, revision == gaia revision. ([https://datazilla.mozilla.org/b2g/testdata/raw/master/43e6b5fa9482809a425286b3cbf429f803585084 example])

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance

2014-08-14T22:03:23Z

Mlee: Added notes re: the fxOS Performance Team's dissolution.

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The team members and contact points below no longer handle these responsibilities on a daily basis.'''''</big>

{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Wander Costa, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee + Jean Gong
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org, '''[mailto:fxos-perf@mozilla.com fxos-perf@mozilla.com]'''
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Meetings=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The meetings and activities below will no longer occur.'''''</big>
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]'''
|-
|}

=Areas=
<big>'''''As of 2014.08.15 this team has been dissolved. Performance responsibilities are transitioned to other [[FirefoxOS/functionalteams|fxOS functional teams]]. The fxOS Performance Areas below are no longer led nor maintained by the listed individuals.'''''</big>
{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation|Automation]]''' || Hubert Figuière & Geo Mealer
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' || Wander Costa
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=== Regression Duty ===
Current areas of regression duty:
* Watch b2gperf start up times https://datazilla.mozilla.org/b2g
* Watch fxos-pert alerts. Currently, limited in scope to start up time regressions.
* Map of Gecko revisions reported by datazilla to their correct revision https://people.mozilla.org/~asasaki/vcs2vcs/gecko-dev/gecko-mapfile
* Get access to Jenkins. File a bug like [https://bugzilla.mozilla.org/show_bug.cgi?id=1036477 bug 1036477]

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]
* [http://charts.mozilla.org/ffos/blockers.html#responsibility=FxOS_Team&project=1.3,1.3T,1.4,2.0 Release Blocking Dashboard]

=Plans=
* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap Doc]
* [https://wiki.mozilla.org/FirefoxOS/Performance/Roadmap Roadmap Wiki (in progress)]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]
** [http://datazilla.readthedocs.org/en/latest/webservice/ Datazilla Web Service Documentation]
*** Use /b2g/testdata/raw endpoint to retrieve data, revision == gaia revision. ([https://datazilla.mozilla.org/b2g/testdata/raw/master/43e6b5fa9482809a425286b3cbf429f803585084 example])

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance/Release Acceptance

2014-08-14T18:51:07Z

Mlee: Removed Homescreen from 2.0 as further changes to 2.0 introduces risk too late in the release cycle.

= Criteria =

== Definitions ==

; First Launch : Milliseconds elapsed from the user-initiated launch of a not-already-in-memory app to the stable display of that app and its visible content. These timings are captured to the '''''moz-app-visually-complete''''' event [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines documented on MDN].
; First Launch Memory : Maximum bytes of RAM used by an application after completing its First Launch.

; Reference Workload : A [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gaia/Hacking#Reference_Workloads standardized collection of application data] preloaded before the test is run.

''Note: All measurements are the median results calculated from multiple iterations of relevant tests. For example, Datazilla's App Launch values are calculated from 30 such iterations.''

== 2.1 ==

* Reference Device: Flame 319MB
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,clock,communications/contacts,communications/dialer,costcontrol,email%20FTU,fm,gallery,settings,sms,video&app=communications/dialer&plot=median First Launch] !! First Launch Memory 
|-
| Calendar || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar&app=calendar&plot=median 1000 ms]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=camera&app=camera&plot=median 1000 ms]
|-
| Clock || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=clock&app=clock&plot=median 1000 ms]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/contacts&app=communications/contacts&plot=median 1000 ms]
|-
| Cost Control || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=costcontrol&app=costcontrol&plot=median 1000 ms]
|-
| Dialer || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median 1000 ms]
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median 1000 ms]
|-
| FM Radio || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median 1000 ms]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median 1000 ms]
|-
| Homescreen || 1000 ms
|-
| Marketplace || 1000 ms
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median 1000 ms]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=sms&app=sms&plot=median 1000 ms]
|-
| Video || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median 1000 ms]
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 2.0 ==

* Reference Device: Flame 319MB
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,clock,communications/contacts,communications/dialer,costcontrol,email%20FTU,fm,gallery,settings,sms,video&app=communications/dialer&plot=median First Launch] 
|-
| Calendar || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar&app=calendar&plot=median 1000 ms]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=camera&app=camera&plot=median 1000 ms]
|-
| Clock || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=clock&app=clock&plot=median 1000 ms]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/contacts&app=communications/contacts&plot=median 1000 ms]
|-
| Cost Control || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=costcontrol&app=costcontrol&plot=median 1000 ms]
|-
| Dialer || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median 1000 ms]
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median 1000 ms]
|-
| FM Radio || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median 1000 ms]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median 1000 ms]
|-
| Marketplace || 1000 ms
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median 1000 ms]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=sms&app=sms&plot=median 1000 ms]
|-
| Video || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median 1000 ms]
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 1.4 ==

* Reference Device: Buri/Hamachi
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! First Launch
|-
| Browser || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=browser&app=browser&plot=median No regression since 1.3]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=camera&app=camera&plot=median No regression since 1.3]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=contacts&app=contacts&plot=median No regression since 1.3]
|-
| Dialer || No regression since 1.3
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=email%20FTU&app=email%20FTU&plot=median No regression since 1.3]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=gallery&app=gallery&plot=median No regression since 1.3]
|-
| Marketplace || No regression since 1.3
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=settings&app=settings&plot=median No regression since 1.3]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=messages&app=messages&plot=median No regression since 1.3]
|}

== 1.3T ==

* Reference Device: Tarako

Acceptance for 1.3T will be determined by reviewing final performance results which will include [https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=90&test=cold_load_time&plot=median cold launch time].

Firefox OS/Performance/Triage

2014-08-13T18:25:21Z

Mlee: /* Blockers */ Hiding 1.3T+ query since that release is done.

=Schedule=

* Triage: Wednesdays from 11am - 12pm PT
* Vidyo: [https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]
* IRC: irc://irc.mozilla.org:6697/#fxos-perf

=Queries=

==Blockers==
* Queries
** [http://mzl.la/1rrkXRr 2.0?]
** [http://mzl.la/1rrkZst 2.0+]
** [http://mzl.la/1tRXdu4 1.4?]
** [http://mzl.la/1tRXjSB 1.4+]





* Query Criteria:
** Open Bugs
** Products: Boot2Gecko Graveyard, Core, Firefox OS, Tech Evangelism, Testing, Toolkit
** B2G blocking as labeled
** Keywords: perf, mlk, footprint OR in the FxOS Performance component

* Triage Actions:
** Ensure bugs have assignees, appropriate needinfos, or otherwise move forward
** Add or modify Scrumbugs tags as needed. Use ''u=<release>'', e.g. ''u=2.0''

* Conventions
** ...'''?''' = blocker nominations = bugs nominated as something that should block that release.
** ...'''+''' = blockers = bugs accepted as being a release blocker.
** Blocking criteria can be found at: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines
** Additional blocking criteria for regressions.
*** Less than 50ms regression, not auto nom.
*** Between 50ms - 100ms regression, use your own discretion.
*** Greater than 100ms, auto nom.

==New Candidates==
* Query:
** [http://mzl.la/1rrm43H New Candidates (Untagged)]

* Query Criteria:
** Open Bugs
** Product: Firefox OS
** Not reviewed or tagged for Scrumbugs
** Perf issue according to one of following
*** Summary containing delay, perf, slow, sluggish
*** Keyword containing mlk, perf, footprint
*** In the FxOS Performance component

* Triage Actions
** Sort by ascending bug ID
** Add '''perf''' keyword and Scrumbugs tags for all FxOS Performance issues.
** Add '''perf-reviewed''' whiteboard for bugs that are not FxOS Performance issues.
** Non-performance issues in the Firefox OS | Performance component should be moved elsewhere.

==Unprioritized Backlog==
* Query:
** [http://mzl.la/1tS0729 Unprioritized Backlog (All Open)]

* Query Criteria:
** Open Bugs
** Products: Boot2Gecko Graveyard, Core, Datazilla, Developer Engagement, Firefox OS, Marketplace, Powertool, Tech Evangelism, Testing
** Not prioritized
** Has Scrumbugs tags
** Keyword containing mlk, perf, footprint

* Triage Actions:
** Set Priority for all bugs covered in each triage session.
** Match [MemShrink:P?] priority when set unless bug is a release blocker.
** Close bugs that no longer reproduce or that no longer match product requirements.
** Identify blockers and relevancy.

=Keywords=

; footprint: Add to bugs regarding memory footprint performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; mlk: Add to bugs regarding memory leak/out-of-memory (OOM) performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; perf: Add to bugs covering regarding all types of performance or performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; regression: Add to bugs where a regression has occurred; previously working functionality has been broken or performance goal is no longer being met.
; regressionwindow-wanted: Add to bugs where the commit that caused the regression needs to be identified.
; qawanted: Add to bugs where performance needs to be verified (or re-verified) by QA. Specific instructions should always accompany this keyword.
This list is not comprehensive, and only includes keywords used very frequently by the FxOS Performance team during triage. For the full list of keywords and their descriptions see: https://bugzilla.mozilla.org/describekeywords.cgi

=Whiteboard Entries=

; [perf-reviewed]: Add to bugs that appear in an Untagged triage but should not be tracked by the FxOS Performance team. Excludes from future triages.
; [MemShrink]: Add to bugs that should be looked at by the [https://wiki.mozilla.org/Performance/MemShrink MemShrink team] responsible for maintaining efficient memory usage on FxOS.
This list is not comprehensive, and only includes whiteboard entries used very frequently by the FxOS Performance team during triage.

=Prioritization=

Prioritization of tasks is defined on a scale of decreasing priority from P1 to P5.

; [P1]: Any bug that is designated a blocker. Can also be used on tasks that we deem critical for our team to complete.
; [P2]: Bugs that are deemed important to solve but are not classified as blockers. Can also be used for critical engineering research tasks.
; [P3]: Lower priority bugs. Can also be used for common engineering research tasks.
; [P4]: Engineering research tasks for open schedules or down-time.
; [P5]: Dated bugs that have not been followed up on recently.

=Scrumbugs Tags=

Scrumbugs tags are added to the Whiteboard field in Bugzilla, but are actually directives to [http://scrumbu.gs Scrumbugs] for how to organize the bugs within sprints and backlogs.

The tags follow the format:

''[c=<component> p=<points> s=<sprint> u=<milestone>]''

Brackets are optional, but will help keep the tags from being accidentally mixed up with other whiteboard entries and not parsed by Scrumbugs. Spacing is significant; no spaces should be on either side of the equals. Order is not significant.

Tags may appear but be left empty, e.g. ''[c= p= s= u=]''. This will be sufficient to direct Scrumbugs to track the bug. Other valid values for tags are explained below.

Not all tags must appear, but our queries expect that any bug tracked by the FxOS Performance team will have the Component tag at minimum.

More information about Scrumbugs can be found on the [http://scrumbu.gs/help/ Scrumbugs Help Page]. Examples may be found on the [http://scrumbu.gs/t/fxos-dev-mlee/ FxOS Performance team's Scrumbugs page].

==c= Component==

The FxOS Performance team is generally less concerned about what module of code a bug affects (the Bugzilla component) than what kind of performance the bug impacts. Components are typically overridden via the Component tag to refer to particular user stories representing broad performance targets.

; (no value): use the component from Bugzilla
; automation: Automation-related
; benchmark: Performance Benchmarks
; boot: Boot Sequence (boot-2-homescreen)
; cpu: Excessive CPU usage
; devtools: Development Tools
; documentation: Documentation
; effect: Perception of cause & effect
; handeye: Hand-Eye coordination
; hardware: Hardware interfacing performance issues.
; memory: Memory leaks or footprint.
; power: Power Management
; profiling: Profiling tools
; progress: Perception of progress
; regression: Broken functionality that previously worked
; startup: Start up time optimizations
; uniformity: Frame Uniformity
; graphics: Uncategorized graphics issue

More information may be found at [[../UserStories]].

==p= Points==

Point values are estimates of effort ranging from 1 to 5 set during Sprint Planning. They can be adjusted during a sprint cycle as their related issues become better understood. Point values are not usually set during triage.

{| border="1" cellpadding="5"
! Points !! Meaning
|-
! (no value)
| Unestimated
|-
! 1
| Clearly understood and trivial.
|-
! 2
| Clearly understood and non-complex.
|-
! 3
| Average, requiring investigation but not significant effort.
|-
! 4
| Difficult, requiring non-trivial investigation and implementation expected to take half or more of a sprint.
|-
! 5
| Very difficult, requiring significant investigation and implementation requiring an entire sprint.
|}

Issues requiring more time than a sprint cycle must be broken into smaller issues that can each be accomplished within a sprint.

==s= Sprint==

The Sprint tag is used to direct Scrumbugs to include the bug into a particular sprint.

The value of this tag, if set, refers to the name of a Scrumbugs sprint. FxOS Performance team sprints follow a date format ''YYYY.MM.DD'', where the date refers to the day the sprint ends in the Pacific Time timezone.

If the tag is included with an unset value, it has no effect.

This tag should not be used with a set value on open bugs, as it interferes with Scrumbugs' ability to migrate the bug from one sprint to the next when necessary. Once specified this way, the bug will always need to be manually managed within Scrumbugs, even if the tag is subsequently removed.

'''A value should only be set for this tag to insert an otherwise untracked bug into the current sprint after the bug has already been resolved'''.

==u= Milestone==

The Milestone tag is actually a repurposing of the Scrumbugs User tag. For the purposes of the FxOS Performance team, it is used to indicate the FxOS Release(s) and/or Device(s) for which the bug is targeted (e.g., ''1.2'', ''1.3'', ''tarako'', etc.)

The value, if set, will be reflected in the User column of [https://scrumbu.gs/p/fxos-perf/ Scrumbugs]. If the value is unset, the tag has no effect and the column will remain empty.

=Cc=

To Cc (Carbon Copy) the perf team in Bugzilla, use perf@fxos-perf.bugs as the address. People interested just need to watch that user in bugzilla. Don't Cc the team list.

Firefox OS/Performance/Release Acceptance

2014-08-05T17:45:09Z

Mlee: Moved 2.0 + 2.1 first launch datazilla links from application name to First Launch column

= Criteria =

== Definitions ==

; First Launch : Milliseconds elapsed from the user-initiated launch of a not-already-in-memory app to the stable display of that app and its visible content. These timings are captured to the '''''moz-app-visually-complete''''' event [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines documented on MDN].
; First Launch Memory : Maximum bytes of RAM used by an application after completing its First Launch.

; Reference Workload : A [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gaia/Hacking#Reference_Workloads standardized collection of application data] preloaded before the test is run.

''Note: All measurements are the median results calculated from multiple iterations of relevant tests. For example, Datazilla's App Launch values are calculated from 30 such iterations.''

== 2.1 ==

* Reference Device: Flame 319MB
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,clock,communications/contacts,communications/dialer,costcontrol,email%20FTU,fm,gallery,settings,sms,video&app=communications/dialer&plot=median First Launch] !! First Launch Memory 
|-
| Calendar || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar&app=calendar&plot=median 1000 ms]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=camera&app=camera&plot=median 1000 ms]
|-
| Clock || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=clock&app=clock&plot=median 1000 ms]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/contacts&app=communications/contacts&plot=median 1000 ms]
|-
| Cost Control || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=costcontrol&app=costcontrol&plot=median 1000 ms]
|-
| Dialer || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median 1000 ms]
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median 1000 ms]
|-
| FM Radio || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median 1000 ms]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median 1000 ms]
|-
| Homescreen || 1000 ms
|-
| Marketplace || 1000 ms
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median 1000 ms]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=sms&app=sms&plot=median 1000 ms]
|-
| Video || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median 1000 ms]
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 2.0 ==

* Reference Device: Flame 319MB
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,clock,communications/contacts,communications/dialer,costcontrol,email%20FTU,fm,gallery,settings,sms,video&app=communications/dialer&plot=median First Launch] 
|-
| Calendar || [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar&app=calendar&plot=median 1000 ms]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=camera&app=camera&plot=median 1000 ms]
|-
| Clock || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=clock&app=clock&plot=median 1000 ms]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/contacts&app=communications/contacts&plot=median 1000 ms]
|-
| Cost Control || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=costcontrol&app=costcontrol&plot=median 1000 ms]
|-
| Dialer || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median 1000 ms]
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median 1000 ms]
|-
| FM Radio || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median 1000 ms]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median 1000 ms]
|-
| Homescreen || 1000 ms
|-
| Marketplace || 1000 ms
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median 1000 ms]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=sms&app=sms&plot=median 1000 ms]
|-
| Video || [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median 1000 ms]
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 1.4 ==

* Reference Device: Buri/Hamachi
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! First Launch
|-
| Browser || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=browser&app=browser&plot=median No regression since 1.3]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=camera&app=camera&plot=median No regression since 1.3]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=contacts&app=contacts&plot=median No regression since 1.3]
|-
| Dialer || No regression since 1.3
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=email%20FTU&app=email%20FTU&plot=median No regression since 1.3]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=gallery&app=gallery&plot=median No regression since 1.3]
|-
| Marketplace || No regression since 1.3
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=settings&app=settings&plot=median No regression since 1.3]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=messages&app=messages&plot=median No regression since 1.3]
|}

== 1.3T ==

* Reference Device: Tarako

Acceptance for 1.3T will be determined by reviewing final performance results which will include [https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=90&test=cold_load_time&plot=median cold launch time].

Firefox OS/Performance/Automation

2014-08-05T02:01:43Z

Mlee: /* Instrumented */

= Firefox OS Performance Automation =

== Goals ==

* Provide developers with timely information regarding the performance of their latest code changes
* Provide product and quality owners with enough information to know whether products will be acceptable
* Give piece of mind when Firefox OS performs well
* Inspire appropriate urgency when Firefox OS does not

== Tools ==
* [[/Tools|Automation Tools]]

== Tests ==

=== Instrumented ===
* [[/Launch Latency|Launch Latency]]
* [[/Subsequent Launch Latency|Relaunch Latency]]
* [[/Frame Rate|Frame Rate]]
* [[/Frame Uniformity|Frame Uniformity]]
* [[/Checkboarding|Checkerboarding]]
* [[/Memory Consumption|Memory Consumption]]
* [[/Battery Life|Battery Life]]
* [[/Power Consumption|Power Consumption]]
* [[/Keyboard Invocation Latency|Keyboard Invocation Latency]]
* [[/Key Click Latency|Key Click Latency]]
* [[/Data Consumption|Data Consumption]]

[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Metric_Template template]

== Development Strategy ==

=== Overview ===

A performance automation metric consists of a type of measurement applied to a series of test cases.

Depending on the metric, these may be one basic test scenario applied to a number of apps (such as launch latency testing) or a number of distinctly designed test cases (such as scenarios for memory or power consumption testing).

The workflow for developing a performance automation test case must be more structured than a standard unit-testing or functional-testing development effort. Reasons are:

* There are many moving parts to pull together for a single test, and often different owners for the moving parts.
* The tests are sometimes more invasive to the system-under-test than a functional test would be. This requires extreme caution; tests can break functionality or even skew their own results.
* Performance tests can be maintenance-intensive. Permanent instrumentation can make the maintenance of the tested code harder too. It's important the test be worth the risk and cost.
* It's very easy to measure the wrong thing, get reasonable looking results, and trust a faulty test or receive false alerts.
* It's very easy to measure the right thing but not control the environment correctly, and trust a faulty test or receive false alerts.
* Performance bugs are hugely expensive to triage, diagnose, and fix; false alerts have significant costs.
* Once the test is running, people don't tend to look for the problems themselves. Tests that don't alert when they should let performance issues slip into field and cause perception of our quality to be lower.
* If performance tests prove untrustworthy, the metric in general will sometimes be written off and even after repair the results may be treated with low priority.

In short, performance tests are a mission-critical system, and require a mission-critical approach. They must be correct, and their behavioral and statistical characteristics need to be well-known. The consequences of having bad performance tests can be worse than the consequences of having no test at all.

Our workflow is described in a series of intermediate deliverables. Reviews for validity and result repeatability are inline with other deliverables to ensure each test brings positive value to Firefox OS.

With only a couple of exceptions, each deliverable depends on the last to be completed before it may be started.

=== Deliverables ===

; Design : Detailed description of the test case's setup needs and procedure, the test procedure, execution details, and results to deliver. This might be for a common scenario, or might be per-case.
; Validity Review : Review by test stakeholders for whether the test case design meets requirements and will measure the right thing. Tests that measure the wrong thing can still give repeatable results, so it is important to review the initial design.
; Workload : Data (a fixture) to be preloaded into the system under test prior to execution. There are default workflows described at [https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/make_options_reference#Reference_Workloads MDN], but some tests may need special-case workflows to be developed.
; Instrumentation : Code either injected into or permanently added to Firefox OS or its applications in order to let automation monitor performance details. Some tests do not need this.
; On-Demand Test : Test that can be run by a developer on command line, try server, or some other way to test a set of arbitrary code.
; Results Review : Review by test stakeholders of a set of results of the implemented test. We sanity check for whether the results look valid (a result frame rate of 70fps on a 60Hz screen would fail this) and whether they are repeatable (reasonably grouped, assuming no code changes). This is also where we can determine or finalize an estimate of test precision, based on real results.
; Published Results : Automated results published to a dashboard or similar display. This usually also implies having an automated triggering and execution mechanism (nightly, on-commit, etc.) to generate them.
; Documentation : Finalized documentation on this wiki and/or MDN of the test case and its usage.

=== Illustration ===

Below are two graphs illustrating the general workflow.

The first is the general order of operations of developing a performance test case, described in the above deliverables. It is split into three milestones. Milestones each result in a final deliverable, and should be each completed as a whole within a single development effort. However, they can be pipelined or freezered on a milestone-by-milestone basis.

The second is a basic bug dependency tree for a performance test case, assuming one bug per deliverable (including reviews) and that all deliverables are necessary.

[[File:Fxos-perf-auto-workflow.png|framed|left|FxOS Performance Automation Development Workflow]]

Firefox OS/Performance/Release Acceptance

2014-08-05T01:44:59Z

Mlee: Added 2.1 Criteria and updated 2.0 & 2.1 to link to 319MB flame results

= Criteria =

== Definitions ==

; First Launch : Milliseconds elapsed from the user-initiated launch of a not-already-in-memory app to the stable display of that app and its visible content. These timings are captured to the '''''moz-app-visually-complete''''' event [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines documented on MDN].
; First Launch Memory : Maximum bytes of RAM used by an application after completing its First Launch.

; Reference Workload : A [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gaia/Hacking#Reference_Workloads standardized collection of application data] preloaded before the test is run.

''Note: All measurements are the median results calculated from multiple iterations of relevant tests. For example, Datazilla's App Launch values are calculated from 30 such iterations.''

== 2.1 ==

* Reference Device: Flame 319MB
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,clock,communications/contacts,communications/dialer,costcontrol,email%20FTU,fm,gallery,settings,sms,video&app=communications/dialer&plot=median First Launch] !! First Launch Memory 
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar&app=calendar&plot=median Calendar] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=camera&app=camera&plot=median Camera] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=clock&app=clock&plot=median Clock] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/contacts&app=communications/contacts&plot=median Contacts] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=costcontrol&app=costcontrol&plot=median Cost Control] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median Dialer] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median Email] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median FM Radio] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median Gallery] || 1000 ms
|-
| Homescreen || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median Settings] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=sms&app=sms&plot=median SMS] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median Video] || 1000 ms
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 2.0 ==

* Reference Device: Flame 319MB
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=bookmark,browser,calendar,camera,clock,communications/contacts,communications/dialer,communications/ftu,contacts,costcontrol,email%20FTU,emergency-call,findmydevice,fm,fm_radio,gallery,homescreen,marketplace,messages,music,operatorvariant,pdfjs,phone,pss,rss,settings,sms,system_pss,system_rss,system_uss,system_vsize,template,usage,uss,video,vsize&app=settings&plot=median First Launch]
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=calendar&app=calendar&plot=median Calendar] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=camera&app=camera&plot=median Camera] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=clock&app=clock&plot=median Clock] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/contacts&app=communications/contacts&plot=median Contacts] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=costcontrol&app=costcontrol&plot=median Cost Control] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median Dialer] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median Email] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median FM Radio] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median Gallery] || 1000 ms
|-
| Homescreen || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median Settings] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=sms&app=sms&plot=median SMS] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame-319MB&range=7&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median Video] || 1000 ms
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 1.4 ==

* Reference Device: Buri/Hamachi
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! First Launch
|-
| Browser || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=browser&app=browser&plot=median No regression since 1.3]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=camera&app=camera&plot=median No regression since 1.3]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=contacts&app=contacts&plot=median No regression since 1.3]
|-
| Dialer || No regression since 1.3
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=email%20FTU&app=email%20FTU&plot=median No regression since 1.3]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=gallery&app=gallery&plot=median No regression since 1.3]
|-
| Marketplace || No regression since 1.3
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=settings&app=settings&plot=median No regression since 1.3]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=messages&app=messages&plot=median No regression since 1.3]
|}

== 1.3T ==

* Reference Device: Tarako

Acceptance for 1.3T will be determined by reviewing final performance results which will include [https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=90&test=cold_load_time&plot=median cold launch time].

Firefox OS/Performance/Release Acceptance

2014-07-25T00:51:06Z

Mlee: Updated terminology from Cold Launch to First Launch and added Relaunch

Firefox OS/Performance/Responsiveness

2014-07-25T00:10:40Z

Mlee: /* Application Startup */ Added Application Launch Presentation and cleaned up Status table

Mozilla's program for advancing Firefox OS responsiveness and perceived performance.

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=progress",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

==Application Startup==
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Responsiveness Guidelines]
* [http://presentboldly.com/eliperelman/firefox-os-app-launch-performance/ Application Launch Performance Presentation]

=== First Launch Events Status [{{bug|996038}}] ===

{| class="wikitable fullwidth-table"
| '''''App''''' || '''''Bug''''' || '''''Status''''' || '''''Branches''''' || '''''Datazilla''''' || '''''Comments'''''
|-
| '''Browser''' || {{bug|837668}} || New || - || No || Being removed in 2.1, not prioritized for 2.0
|-
| '''Calendar''' || {{bug|837671}} || Resolved || master, v2.0 || Yes
|-
| '''Camera''' || {{bug|1015385}} || Resolved || master, v2.0 || Yes || Missing from Datazilla in v2.0 results
|-
| '''Clock''' || {{bug|837668}} || Resolved || master, v2.0 || No || Missing in Datazilla, script timeout investigation in {{bug|1037500}}
|-
| '''Contacts''' || {{bug|1015388}} || Resolved || master, v2.0 || Yes
|-
| '''Dialer''' || {{bug|837668}} || Resolved || master, v2.0 || Yes
|-
| '''Email''' || {{bug|837677}} || Resolved || master, v2.0 || Yes
|-
| '''FM Radio''' || {{bug|1015412}} || Resolved || master, v2.0 || Yes
|-
| '''Gallery''' || {{bug|837674}} || Resolved || master, v2.0 || Yes
|-
| '''Marketplace''' || {{bug|837668}} || Resolved || master || No || Missing in Datazilla, tests failed due to no network connectivity, requires certified to resolve
|-
| '''Music''' || {{bug|837675}} || Assigned || - || No || r-, needs revised
|-
| '''Settings''' || {{bug|1015405}} || Resolved || master, v2.0 || Yes
|-
| '''SMS''' || {{bug|1015390}} || Resolved || master, v2.0 || Yes || Missing in Datazilla for v2.0 due to {{bug|1042532}}
|-
| '''Template''' || {{bug|1015391}} || Assigned || - || No || In progress
|-
| '''Usage''' || {{bug|837678}} || Resolved || master, v2.0 || Yes || Missing in Datazilla for v2.0 due to {{bug|1042532}}
|-
| '''Video''' || {{bug|837676}} || Resolved || master, v2.0 || Yes
|-
|}

==References==

===Videos===

* [https://www.youtube.com/watch?v=7ubJzEi3HuA Fluent 2014: Ilya Grigorik, "Speed, Performance, and Human Perception"]
* [https://www.youtube.com/watch?v=znjy4Kl3IfU Fluent 2014: Steve Souders, "The Perception of Speed"]
* [https://www.youtube.com/watch?v=ZpFdyfs03Ug SXSW 2012: Andy Hume: "CSS for Grownups"]

===Documents===

* [https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity UI Synchronicity]
* [https://en.wikipedia.org/wiki/List_of_cognitive_biases Cognitive Biases]
* [http://coglode.com/ Cognitive Load]: The latest behavioral economics & consumer psychology research distilled down into helpful little brain gems.
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Writing Efficient CSS]
** [http://www.masonchang.com/2013/12/5/the-will-animate-css-property will-change property]
* [http://stevesouders.com/ High Performance Web Sites (Steve Souders)]
* [http://jankfree.org/ Jank-free Web]
* [https://mozilla.app.box.com/s/aww17rx74k7fjds5vada Perceived Performance Introduction]
* [http://bit.ly/1sDmepL Tarako Responsive Performance Analysis]

Firefox OS/Performance/Roadmap

2014-07-24T14:00:13Z

Mlee: /* Summary */

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

{| class="wikitable"
|-
! Metric
! fxOS 2.0
! fxOS 2.1
! fxOS 2.2
! fxOS 2.3
! TBD
! Goal
|-
|'''App First Launch + Relaunch'''
| App Launch tracking for Core Apps {{ bug|996038}}
|
|
|
|
*Measure Relaunch time for Core Apps {{bug|TBD }}
*Measure First Launch for third party apps {{bug|to_be_filed}}
|
*No Regressions from previous release
*App first launch < 1.0 second
*< or equal to competitive OSs
|-
|'''Memory'''
|
|
|
|
|
*Publishing memory usage on system and per app basis {{bug|to_be_filed}}
|
*After loading on 256Mbytes device, should have 80 Mbytes free for apps to run
*Lowest use of Memory among smartphones OS.
|-
|'''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}}
|
*High frame uniformity: std deviation of velocity
*High smootheness: std deviation of velocity would be less that equal to X
**No Jank, No Checkerboarding, ~ 60 fps
*Equal to or better than Competitive OSs
|-
|'''Power Consumption'''
|
|
|
|
|
*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
|-
|'''Responsiveness'''
|
|
|
|
|Common micro-interactions perceived as responsive
|-
|'''MTBF'''
|
|
|
|
|
|100 hours
|-
|'''WebRTC'''
|
|
|
|
|
|
|-
|'''Browser Benchmarks'''
|
|
|
|
|
|Competitive with Chrome browser on Android
|}

Firefox OS/Performance/Release Acceptance

2014-07-24T06:31:16Z

Mlee: /* 2.0 */ Added Homescreen

= Criteria =

== Definitions ==

; Cold Launch Time : Milliseconds elapsed from the user-initiated launch of a not-already-in-memory app to the stable display of that app and its visible content.

; Reference Workload : A [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gaia/Hacking#Reference_Workloads standardized collection of application data] preloaded before the test is run.

''Note: All measurements are the median results calculated from multiple iterations of relevant tests. For example, Datazilla's App Cold Launch values are calculated from 30 such iterations.''

== 2.0 ==

* Reference Device: Flame
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,communications/contacts,communications/dialer,email%20FTU,fm,gallery,settings,video&app=settings&plot=median Cold Launch Time]
|-
| Browser || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=calendar&app=calendar&plot=median Calendar] || 1000 ms
|-
| Camera || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=communications/contacts&app=communications/contacts&plot=median Contacts] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median Dialer] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median Email] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median FM Radio] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median Gallery] || 1000 ms
|-
| Homescreen || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median Settings] || 1000 ms
|-
| SMS || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median Video] || 1000 ms
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 1.4 ==

* Reference Device: Buri/Hamachi
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! Cold Launch Time
|-
| Browser || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=browser&app=browser&plot=median No regression since 1.3]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=camera&app=camera&plot=median No regression since 1.3]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=contacts&app=contacts&plot=median No regression since 1.3]
|-
| Dialer || No regression since 1.3
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=email%20FTU&app=email%20FTU&plot=median No regression since 1.3]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=gallery&app=gallery&plot=median No regression since 1.3]
|-
| Marketplace || No regression since 1.3
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=settings&app=settings&plot=median No regression since 1.3]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=messages&app=messages&plot=median No regression since 1.3]
|}

== 1.3T ==

* Reference Device: Tarako

Acceptance for 1.3T will be determined by reviewing final performance results which will include [https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=90&test=cold_load_time&plot=median cold launch time].

Firefox OS/Performance

2014-07-24T06:05:18Z

Mlee: /* Areas */

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Wander Costa, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org, '''[mailto:fxos-perf@mozilla.com fxos-perf@mozilla.com]'''
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Meetings=
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]'''
|-
|}

=Areas=

{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation|Automation]]''' || Hubert Figuière & Geo Mealer
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' || Wander Costa
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=== Regression Duty ===
Current areas of regression duty:
* Watch b2gperf start up times https://datazilla.mozilla.org/b2g
* Watch fxos-pert alerts. Currently, limited in scope to start up time regressions.
* Map of Gecko revisions reported by datazilla to their correct revision https://people.mozilla.org/~asasaki/vcs2vcs/gecko-dev/gecko-mapfile
* Get access to Jenkins. File a bug like [https://bugzilla.mozilla.org/show_bug.cgi?id=1036477 bug 1036477]

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]
* [http://charts.mozilla.org/ffos/blockers.html#responsibility=FxOS_Team&project=1.3,1.3T,1.4,2.0 Release Blocking Dashboard]

=Plans=

* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]
** [http://datazilla.readthedocs.org/en/latest/webservice/ Datazilla Web Service Documentation]
*** Use /b2g/testdata/raw endpoint to retrieve data, revision == gaia revision. ([https://datazilla.mozilla.org/b2g/testdata/raw/master/43e6b5fa9482809a425286b3cbf429f803585084 example])

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance/Automation

2014-07-24T06:01:52Z

Mlee: /* Firefox OS Performance Automation */

= Firefox OS Performance Automation =

== Goals ==

* Provide developers with timely information regarding the performance of their latest code changes
* Provide product and quality owners with enough information to know whether products will be acceptable
* Give piece of mind when Firefox OS performs well
* Inspire appropriate urgency when Firefox OS does not

== Tools ==
* [[/Tools|Automation Tools]]

== Tests ==

=== Instrumented ===
* [[/Launch Latency|Launch Latency]]
* [[/Subsequent Launch Latency|Subsequent Launch Latency]]
* [[/Frame Rate|Frame Rate]]
* [[/Frame Uniformity|Frame Uniformity]]
* [[/Checkboarding|Checkerboarding]]
* [[/Memory Consumption|Memory Consumption]]
* [[/Battery Life|Battery Life]]
* [[/Power Consumption|Power Consumption]]
* [[/Keyboard Invocation Latency|Keyboard Invocation Latency]]
* [[/Key Click Latency|Key Click Latency]]
* [[/Data Consumption|Data Consumption]]

[http://wiki.mozilla.org/FirefoxOS/Performance/Automation/Metric_Template template]

== Development Strategy ==

=== Overview ===

A performance automation metric consists of a type of measurement applied to a series of test cases.

Depending on the metric, these may be one basic test scenario applied to a number of apps (such as launch latency testing) or a number of distinctly designed test cases (such as scenarios for memory or power consumption testing).

The workflow for developing a performance automation test case must be more structured than a standard unit-testing or functional-testing development effort. Reasons are:

* There are many moving parts to pull together for a single test, and often different owners for the moving parts.
* The tests are sometimes more invasive to the system-under-test than a functional test would be. This requires extreme caution; tests can break functionality or even skew their own results.
* Performance tests can be maintenance-intensive. Permanent instrumentation can make the maintenance of the tested code harder too. It's important the test be worth the risk and cost.
* It's very easy to measure the wrong thing, get reasonable looking results, and trust a faulty test or receive false alerts.
* It's very easy to measure the right thing but not control the environment correctly, and trust a faulty test or receive false alerts.
* Performance bugs are hugely expensive to triage, diagnose, and fix; false alerts have significant costs.
* Once the test is running, people don't tend to look for the problems themselves. Tests that don't alert when they should let performance issues slip into field and cause perception of our quality to be lower.
* If performance tests prove untrustworthy, the metric in general will sometimes be written off and even after repair the results may be treated with low priority.

In short, performance tests are a mission-critical system, and require a mission-critical approach. They must be correct, and their behavioral and statistical characteristics need to be well-known. The consequences of having bad performance tests can be worse than the consequences of having no test at all.

Our workflow is described in a series of deliverables to ensure the tests will be good. Reviews for validity and result repeatability are inline with other deliverables to ensure each test brings positive value to Firefox OS.

With only a couple of exceptions, each deliverable depends on the last to be completed before it may be started.

=== Deliverables ===

; Design : Detailed description of the test case's setup needs and procedure, the test procedure, execution details, and results to deliver. This might be for a common scenario, or might be per-case.
; Validity Review : Review by test stakeholders for whether the test case design meets requirements and will measure the right thing. Tests that measure the wrong thing can still give repeatable results, so it is important to review the initial design.
; Workload : Data (a fixture) to be preloaded into the system under test prior to execution. There are default workflows described at [https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/make_options_reference#Reference_Workloads MDN], but some tests may need special-case workflows to be developed.
; Instrumentation : Code either injected into or permanently added to Firefox OS or its applications in order to let automation monitor performance details. Some tests do not need this.
; On-Demand Test : Test that can be run by a developer on command line, try server, or some other way to test a set of arbitrary code.
; Results Review : Review by test stakeholders of a set of results of the implemented test. This is a sanity check for whether the results look like something valid (a result frame rate of 70fps on a 60Hz screen would fail this, for example) and whether they are essentially repeatable (reasonably grouped, assuming no code changes).
; Published Results : Automated results published to a dashboard or similar display. This usually also implies having an automated triggering and execution mechanism (nightly, on-commit, etc.) to generate them.
; Documentation : Finalized documentation on this wiki and/or MDN of the test case and its usage.

=== Illustration ===

Below are two graphs illustrating the general workflow.

The first is the general order of operations of developing a performance test case, described in the above deliverables. It is split into three milestones. Milestones each result in a final deliverable, and should be each completed as a whole within a single development effort. However, they can be pipelined or freezered on a milestone-by-milestone basis.

The second is a basic bug dependency tree for a performance test case, assuming one bug per deliverable (including reviews) and that all deliverables are necessary.

[[File:Fxos-perf-auto-workflow.png|framed|left|FxOS Performance Automation Development Workflow]]

Firefox OS/Performance/Automation/Tools

2014-07-24T05:51:00Z

Mlee: /* References */

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=automation",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

==Performance==
There are two automated performance testing tools for Gaia; '''''b2gperf''''' and '''''make test-perf'''''. Both use [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette marionette].

* '''b2gperf'''
** An external Python tool maintained by the [[Auto-tools/The_Ateam|A-team]].
** Source code and documentation are hosted on github at https://github.com/mozilla/b2gperf

== Running b2gperf ==
# Install reqs with 'pip install b2gperf'
# Update reqs with 'pip install --upgrade b2gperf'
# run 'adb forward tcp:2828 tcp:2828' - This lets marionette connect to the device
# Run b2g perf with 'b2gperf --delay=10 --reset --iterations=30 AppNameHere'. For example, to run settings, run 'b2gperf --delay=10 --reset --iterations=30 Settings'. CASE SENSITIVE

== Make test-perf ==
* The in-tree Gaia testing framework maintained by the [[FirefoxOS/Performance|FirefoxOS Performance]] team and [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Gaia_performance_tests documented on MDN].
* '''Code'''
** [https://github.com/mozilla-b2g/gaia/blob/master/bin/gaia-perf-marionette Runner]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/basemozperf.js Reporter]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/consolemozperf.js Reporter : console]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/jsonmozperf.js Reporter : json]
** [https://github.com/mozilla-b2g/gaia/tree/master/tests/performance Source]
* '''Tests'''
** See ''<APP_NAME>/test/performance'' folders within the [https://github.com/mozilla-b2g/gaia/tree/master/apps Gaia] repository.
** Examples
*** [https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/test/performance Dialer]
*** [https://github.com/mozilla-b2g/gaia/tree/master/apps/settings/test/performance Settings]

==Endurance==
* [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Endurance Endurance Tests]

==Integration==
* [https://developer.mozilla.org/en-US/docs/Marionette/Marionette_JavaScript_Tools Marionette JS Tools]
* [https://github.com/mozilla-b2g/marionette-js-runner/blob/master/README.md Marionette JS Tools ReadMe]

==References==
* [[../FPS|FPS via Eideticker]]
* [https://fxos-perf.etherpad.mozilla.org/2013-07-17-kickoff Performance Automation Kickoff]
* [[/Regression_Detection_Requirements|Regression Detection Requirements]]

Firefox OS/Performance/Automation Testing/FPS

2014-07-24T05:49:12Z

Mlee: Mlee moved page FirefoxOS/Performance/Automation Testing/FPS to FirefoxOS/Performance/Automation/FPS

#REDIRECT [[FirefoxOS/Performance/Automation/FPS]]

Firefox OS/Performance/Automation/FPS

2014-07-24T05:49:12Z

Mlee: Mlee moved page FirefoxOS/Performance/Automation Testing/FPS to FirefoxOS/Performance/Automation/FPS

==FPS Measurement and CI Roadmap==

* Goal: Daily high-speed camera measurement of FPS in critical areas all actively developed branches with comparisons against "waterline" numbers, with notifications of improvements and regressions.
** Method: Eideticker - high speed camera measurement
** Frequency: Daily
** Targets
*** Nightly builds of all branches that have active development
*** Various app screens and continuous actions in or between screens
*** Production/reference devices
** Comparisons: Must be able to set "waterlines" to compare results against. Examples are: previous release, chipset vendor reference numbers, target numbers from Mozilla UX performance guidelines.

'''Teams'''
* FxOS Perf Team
* Automation Team
* Release Engineering (?)

'''TBD'''
* Enumerate all test scenarios and workloads (eg, Homescreen, scrolling Gallery, scrolling/panning web content, etc) which need to be measured
* Which device(s) to measure
* Need other teams to correct & update the roadmap items below

'''Roadmap'''

{| class="wikitable fullwidth-table"
| TASK || TEAM || OWNER || STATUS
|-
| High-speed camera measurement of FPS on device(s) || || ||
|-
| Automation of measurement || || ||
|-
| Automated builds to be measured || || ||
|-
| Automatedly test nightly builds || || ||
|-
| Report results to Datazilla || || ||
|-
| Per-test multiple waterline support || || ||
|-
| Notifications of improvement/regression over x% || || ||
|}

Firefox OS/Performance/Automation Testing/Regression Detection Requirements

2014-07-24T05:47:36Z

Mlee: Mlee moved page FirefoxOS/Performance/Automation Testing/Regression Detection Requirements to FirefoxOS/Performance/Automation/Tools/Regression Detection Requirements

#REDIRECT [[FirefoxOS/Performance/Automation/Tools/Regression Detection Requirements]]

Firefox OS/Performance/Automation/Tools/Regression Detection Requirements

2014-07-24T05:47:35Z

Mlee: Mlee moved page FirefoxOS/Performance/Automation Testing/Regression Detection Requirements to FirefoxOS/Performance/Automation/Tools/Regression Detection Requirements

==Automated Performance Regression Detection==

===Parameters===
As of 19 June, 2014, the current rate of changesets in Gaia is around 2-3 per hour and the rate of revisions to Gecko is around 12-15 per hour. Given those numbers, we would need 45-50 flame devices (3 * 15 + 5 = 50) dedicated to only regression detection to test every commit. And even with that, we would be limited to test runs that take less than an hour to flash, and test.

There is a smarter way to accomplish this task with much fewer devices. Mason's [https://github.com/changm/BackoutBot BackoutBot] has demonstrated that with 4-5 Flame devices, we can test every Gaia changeset. The real difficulty comes when trying to test every Gecko, so the strategy is to avoid that altogether.

If the automated testing framework monitors the Gecko repo and updates Gecko every time 16 revisions or 1 hour goes by--whichever is sooner--then we only have to add an aditional 3 devices to the pool to be able to keep up with Gecko. Whenever we detect a regression in Gecko, we will task three of the Flame devices to do a bisection of the revisions since the last Gecko update. By limiting the number of revisions 16, we can be certain that the bisection will take no more than 4 test runs (i.e. log2 16 = 4). If we use three devices, we can test 2 steps at a time. One device tests the current middle while the other two test the middles for the next stage. Once we know if the current middle is good or bad, we know which of the next stage middles to look at. If we repeat once more, we'll have bisected all 16 in 2 test passes.

===Requirements===

* 8-10 Flame devices.
* Flashable builds for every Gecko commit.
* Automated runs of make test-perf
* Automated regression detection tool

===Regression Detection Strategy===

The strategy for finding discreet shifts in the mean values of test results, despite the noise, is based on using step detection algorithms. Probably the simplest approach would be to use [https://en.wikipedia.org/wiki/K-means_clustering k-means clustering] to detect discreet groupings, or "modes", of the means of the test runs.

To visualize what the k-means clustering would get us, let's examine recent data from the Clock app on datazilla. The data points are the mean value for cold launch time measured by b2gperf over 30 runs. The datazilla plot looks like this:

[[File:Clock_app_clean.png|800px]]

Running the data through a k-means clustering algorithm, the data points get clustered together into groups as illustrated in the image below. Each color represents a distinct cluster. The clustering algorithms have a few tunable parameters for deciding if a data point "fits" in an existing cluster or should become it's own cluster. This acts as like a wideband, low aplitude filter and greatly reduces false positives caused by entropy rather than legitimate regressions. once the clustering happens, all data samples in a given cluster are set to the mean value of the cluster. The bottom image shows the flat lines representing all data points in each cluster having the same value.

[[File:Clock_app_clustered.png|800px]]

After clustering, the regression detection algorithm uses a sliding widow of a fixed number of data points. The width of the window is tunable. Using a sliding window acts as a low pass filter and the width of the window sets the cutoff frequency. To put it in plain terms, if the sliding window is 4 samples wide, any 2 adjacent data points that fall into their own cluster and are bookended by data points in another cluster will get ignored. In the picture below, the yellow cluster is only a single data point that is bookended by data points in the purple cluster. A sliding window equal to or greater than 3 would reject the yellow cluster from the step detection as outlier noise.

[[File:Clock_app_colored.png|800px]]

After the sliding window filters out the high frequency, the step detection pass walks along in time order and examines what happened each time there is a transition from one cluster to the next. If there is a "positive" transition (e.g. cluster_mean1 - cluster_mean2 > 0) it will interpret that as an increase in the test results mean and flag it as a regression--assuming lower numbers are better. It is also able to detect "negative" transitions where the test results mean shifts downward and actually gets better.

Firefox OS/Performance/Automation Testing

2014-07-24T05:46:13Z

Mlee: Mlee moved page FirefoxOS/Performance/Automation Testing to FirefoxOS/Performance/Automation/Tools: Simplifying hierarchy now that additional automation content is being created: https://wiki.mozilla.org/FirefoxOS/Performance/Automation/Test_Te...

#REDIRECT [[FirefoxOS/Performance/Automation/Tools]]

Firefox OS/Performance/Automation/Tools

2014-07-24T05:46:12Z

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=automation",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

==Performance==
There are two automated performance testing tools for Gaia; '''''b2gperf''''' and '''''make test-perf'''''. Both use [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette marionette].

* '''b2gperf'''
** An external Python tool maintained by the [[Auto-tools/The_Ateam|A-team]].
** Source code and documentation are hosted on github at https://github.com/mozilla/b2gperf

== Running b2gperf ==
# Install reqs with 'pip install b2gperf'
# Update reqs with 'pip install --upgrade b2gperf'
# run 'adb forward tcp:2828 tcp:2828' - This lets marionette connect to the device
# Run b2g perf with 'b2gperf --delay=10 --reset --iterations=30 AppNameHere'. For example, to run settings, run 'b2gperf --delay=10 --reset --iterations=30 Settings'. CASE SENSITIVE

== Make test-perf ==
* The in-tree Gaia testing framework maintained by the [[FirefoxOS/Performance|FirefoxOS Performance]] team and [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Gaia_performance_tests documented on MDN].
* '''Code'''
** [https://github.com/mozilla-b2g/gaia/blob/master/bin/gaia-perf-marionette Runner]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/basemozperf.js Reporter]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/consolemozperf.js Reporter : console]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/jsonmozperf.js Reporter : json]
** [https://github.com/mozilla-b2g/gaia/tree/master/tests/performance Source]
* '''Tests'''
** See ''<APP_NAME>/test/performance'' folders within the [https://github.com/mozilla-b2g/gaia/tree/master/apps Gaia] repository.
** Examples
*** [https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/test/performance Dialer]
*** [https://github.com/mozilla-b2g/gaia/tree/master/apps/settings/test/performance Settings]

==Endurance==
* [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Endurance Endurance Tests]

==Integration==
* [https://developer.mozilla.org/en-US/docs/Marionette/Marionette_JavaScript_Tools Marionette JS Tools]
* [https://github.com/mozilla-b2g/marionette-js-runner/blob/master/README.md Marionette JS Tools ReadMe]

==References==
* [[/FPS|FPS via Eideticker]]
* [https://fxos-perf.etherpad.mozilla.org/2013-07-17-kickoff Performance Automation Kickoff]
* [[/Regression_Detection_Requirements|Regression Detection Requirements]]

Firefox OS/Performance/Memory

2014-07-20T22:05:29Z

Mlee: /* Background */

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=memory",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

== Background ==
* [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Out_of_memory_management_on_Firefox_OS Firefox OS Out of Memory (OOM) Management]
* [http://www.elinux.org/Android_Memory_Usage Android Memory Types]
* [[FirefoxOS/Performance/Memory/OOMKiller|Out-of-Memory Killer]]
* [[Performance/MemShrink|MemShrink Project]]

== Tools ==
* Cross-Platform Tools
** [[Performance/MemShrink/DMD|Dark Matter Detector (DMD)]]
** [[Performance:Leak_Tools#What_leak_tools_do_we_have.3F|Leak Detection Tools]]
* Firefox OS Specific Tools
** [[FirefoxOS/Performance/Memory/ADB Tools|ADB Command Line Tools]]
** [https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Developer_settings#App_memory App Developer Memory Overlay]
** (Future) Capture memory usage in SPS profiler and cleopatra ({{bug|988332}})

== Debugging ==
* [https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Debugging_OOMs Out-of-Memory Events (OOMs) on Firefox OS]
* [https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_memory_leaks Leaks in Gecko]
* [[FirefoxOS/Performance/Memory/Transients|Transient Memory Spikes]]

== Memory Usage in Automation ==
* [https://areweslimyet.com/ Are We Slim Yet]
* Firefox OS Datazilla
** App Memory
*** browser ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=browser_memory hamachi])
*** calendar ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=calendar_memory hamachi])
*** clock ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=clock_memory hamachi])
*** contacts ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=communications/contacts_memory hamachi])
*** dialer ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=communications/dialer_memory hamachi])
*** fm radio ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=fm_memory hamachi])
*** gallery ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=gallery_memory hamachi])
*** music ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=music_memory hamachi])
*** settings ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=settings_memory hamachi])
*** sms ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=sms_memory hamachi])
*** video ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=video_memory hamachi])
** Parent Process Memory - Endurance Tests
*** Add Contact ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_add_contact hamachi])
*** Delete Contact ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_add_delete_contact hamachi])
*** Browser Wifi ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_browser_wifi hamachi])
*** Camera Photo ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_camera_photo hamachi])
*** Camera Video ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_camera_video hamachi])
*** FM Radio Play ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_fmradio_play hamachi])
*** Gallery Flick ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_gallery_flick hamachi])
*** Launch Phone ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_launch_phone hamachi])
*** Lock Screen ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_lock_screen hamachi])
*** Set Alarm ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_set_alarm hamachi])
*** SMS Send/Receive ([https://datazilla.mozilla.org/b2g/?branch=master&range=90&plot=median&device=hamachi&test=endurance_sms_send_receive hamachi])

==References==
* [https://etherpad.mozilla.org/e3fTHj5FV6 MemShrink Priorities]

__FORCETOC__

Firefox OS/Performance/Release Acceptance

2014-07-19T23:58:54Z

Mlee: /* 2.0 */ Added Calendar & Contacts Datazilla Links

= Criteria =

== Definitions ==

; Cold Launch Time : Milliseconds elapsed from the user-initiated launch of a not-already-in-memory app to the stable display of that app and its visible content.

; Reference Workload : A [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gaia/Hacking#Reference_Workloads standardized collection of application data] preloaded before the test is run.

''Note: All measurements are the median results calculated from multiple iterations of relevant tests. For example, Datazilla's App Cold Launch values are calculated from 30 such iterations.''

== 2.0 ==

* Reference Device: Flame
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,communications/contacts,communications/dialer,email%20FTU,fm,gallery,settings,video&app=settings&plot=median Cold Launch Time]
|-
| Browser || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=calendar&app=calendar&plot=median Calendar] || 1000 ms
|-
| Camera || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=communications/contacts&app=communications/contacts&plot=median Contacts] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median Dialer] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median Email] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median FM Radio] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median Gallery] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median Settings] || 1000 ms
|-
| SMS || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median Video] || 1000 ms
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 1.4 ==

* Reference Device: Buri/Hamachi
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! Cold Launch Time
|-
| Browser || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=browser&app=browser&plot=median No regression since 1.3]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=camera&app=camera&plot=median No regression since 1.3]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=contacts&app=contacts&plot=median No regression since 1.3]
|-
| Dialer || No regression since 1.3
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=email%20FTU&app=email%20FTU&plot=median No regression since 1.3]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=gallery&app=gallery&plot=median No regression since 1.3]
|-
| Marketplace || No regression since 1.3
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=settings&app=settings&plot=median No regression since 1.3]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=messages&app=messages&plot=median No regression since 1.3]
|}

== 1.3T ==

* Reference Device: Tarako

Acceptance for 1.3T will be determined by reviewing final performance results which will include [https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=90&test=cold_load_time&plot=median cold launch time].

Firefox OS/Performance/Responsiveness

2014-07-18T18:57:39Z

Mlee: /* Progress towards new startup events */ Updated to use Bugzilla template & sorted by App

Mozilla's program for advancing Firefox OS responsiveness and perceived performance.

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=progress",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

==Application Startup==
* [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines Responsiveness Guidelines]

=== Progress towards {{bug|996038}} new startup events ===

{| class="wikitable fullwidth-table"
| '''App''' || '''Bug''' || '''Status''' || '''Branches''' || '''In Datazilla''' || '''Comments'''
|-
| '''Calendar''' || {{bug|837671}} || Resolved || master, v2.0 || Yes
|-
| '''Camera''' || {{bug|1015385}} || Resolved || master, v2.0 || Yes || Missing from Datazilla in v2.0 results
|-
| '''Contacts''' || {{bug|1015388}} || Resolved || master, v2.0 || Yes
|-
| '''Dialer''' || {{bug|837668}} || Resolved || master, v2.0 || Yes
|-
| '''Email''' || {{bug|837677}} || Resolved || master, v2.0 || Yes
|-
| '''FM Radio''' || {{bug|1015412}} || Resolved || master, v2.0 || Yes
|-
| '''Gallery''' || {{bug|837674}} || Resolved || master, v2.0 || Yes
|-
| '''Settings''' || {{bug|1015405}} || Resolved || master, v2.0 || Yes
|-
| '''Video''' || {{bug|837676}} || Resolved || master, v2.0 || Yes
|-
| '''Browser''' || {{bug|837668}} || New || - || No || Being removed in 2.1, not prioritized for 2.0
|-
| '''Clock''' || {{bug|837668}} || Resolved || master, v2.0 || No || Missing in Datazilla, script timeout investigating in {{bug|1037500}}
|-
| '''Marketplace''' || {{bug|837668}} || Resolved || master || No || Missing in Datazilla, tests failed from no network connectivity
|-
| '''Music''' || {{bug|837675}} || Assigned || - || No || r-, needs revised
|-
| '''SMS''' || {{bug|1015390}} || Assigned || - || No || r+, awaiting check-in and v2.0 uplift
|-
| '''Template''' || {{bug|1015391}} || Assigned || - || No || In progress
|-
| '''Usage''' || {{bug|837678}} || Assigned || - || No || r+, awaiting check-in and v2.0 uplift
|-
|}

==References==

===Videos===

* [https://www.youtube.com/watch?v=7ubJzEi3HuA Fluent 2014: Ilya Grigorik, "Speed, Performance, and Human Perception"]
* [https://www.youtube.com/watch?v=znjy4Kl3IfU Fluent 2014: Steve Souders, "The Perception of Speed"]
* [https://www.youtube.com/watch?v=ZpFdyfs03Ug SXSW 2012: Andy Hume: "CSS for Grownups"]

===Documents===

* [https://developer.mozilla.org/en-US/Apps/Build/Performance/UI_Synchronicity UI Synchronicity]
* [https://en.wikipedia.org/wiki/List_of_cognitive_biases Cognitive Biases]
* [http://coglode.com/ Cognitive Load]: The latest behavioral economics & consumer psychology research distilled down into helpful little brain gems.
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Writing Efficient CSS]
** [http://www.masonchang.com/2013/12/5/the-will-animate-css-property will-change property]
* [http://stevesouders.com/ High Performance Web Sites (Steve Souders)]
* [http://jankfree.org/ Jank-free Web]
* [https://mozilla.app.box.com/s/aww17rx74k7fjds5vada Perceived Performance Introduction]
* [http://bit.ly/1sDmepL Tarako Responsive Performance Analysis]

Firefox OS/Performance/Automation/Tools

2014-07-18T07:31:16Z

Mlee: Added links to make test-perf source code

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=automation",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

==Performance==
There are two automated performance testing tools for Gaia; '''''b2gperf''''' and '''''make test-perf'''''. Both use [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette marionette].

* '''b2gperf'''
** An external Python tool maintained by the [[Auto-tools/The_Ateam|A-team]].
** Source code and documentation are hosted on github at https://github.com/mozilla/b2gperf

== Running b2gperf ==
# Install reqs with 'pip install b2gperf'
# Update reqs with 'pip install --upgrade b2gperf'
# run 'adb forward tcp:2828 tcp:2828' - This lets marionette connect to the device
# Run b2g perf with 'b2gperf --delay=10 --reset --iterations=30 AppNameHere'. For example, to run settings, run 'b2gperf --delay=10 --reset --iterations=30 Settings'. CASE SENSITIVE

== Make test-perf ==
* The in-tree Gaia testing framework maintained by the [[FirefoxOS/Performance|FirefoxOS Performance]] team and [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Gaia_performance_tests documented on MDN].
* '''Code'''
** [https://github.com/mozilla-b2g/gaia/blob/master/bin/gaia-perf-marionette Runner]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/basemozperf.js Reporter]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/consolemozperf.js Reporter : console]
** [https://github.com/mozilla-b2g/gaia/blob/master/tests/reporters/jsonmozperf.js Reporter : json]
** [https://github.com/mozilla-b2g/gaia/tree/master/tests/performance Source]
* '''Tests'''
** See ''<APP_NAME>/test/performance'' folders within the [https://github.com/mozilla-b2g/gaia/tree/master/apps Gaia] repository.
** Examples
*** [https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/test/performance Dialer]
*** [https://github.com/mozilla-b2g/gaia/tree/master/apps/settings/test/performance Settings]

==Endurance==
* [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Endurance Endurance Tests]

==Integration==
* [https://developer.mozilla.org/en-US/docs/Marionette/Marionette_JavaScript_Tools Marionette JS Tools]
* [https://github.com/mozilla-b2g/marionette-js-runner/blob/master/README.md Marionette JS Tools ReadMe]

==References==
* [[/FPS|FPS via Eideticker]]
* [https://fxos-perf.etherpad.mozilla.org/2013-07-17-kickoff Performance Automation Kickoff]
* [[/Regression_Detection_Requirements|Regression Detection Requirements]]

Firefox OS/Performance/Automation/Tools

2014-07-18T06:19:59Z

Mlee: /* Make test perf */

==Progress==
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=automation",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

==Performance==
There are two automated performance testing tools for Gaia; '''''b2gperf''''' and '''''make test-perf'''''. Both use [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette marionette].

* '''b2gperf'''
** An external Python tool maintained by the [[Auto-tools/The_Ateam|A-team]].
** Source code and documentation are hosted on github at https://github.com/mozilla/b2gperf

== Running B2g Perf ==
# Install reqs with 'pip install b2gperf'
# Update reqs with 'pip install --upgrade b2gperf'
# run 'adb forward tcp:2828 tcp:2828' - This lets marionette connect to the device
# Run b2g perf with 'b2gperf --delay=10 --reset --iterations=30 AppNameHere'. For example, to run settings, run 'b2gperf --delay=10 --reset --iterations=30 Settings'. CASE SENSITIVE

== Make test perf ==
* Gaia Test Framework aka '''make test-perf'''
** In-tree testing framework for gaia maintained by the [[FirefoxOS/Performance|FirefoxOS Performance]] team.
** Documented on MDN at https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Gaia_performance_tests
** Contains app-specific tests
*** [https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/test/performance Dialer Perf Tests]
*** See ''<APP_NAME>/test/performance'' folders within the [https://github.com/mozilla-b2g/gaia/tree/master/apps Gaia Repo] for more performance tests.

* [[/FPS|FPS via Eideticker]]

==Endurance==
* [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Endurance Endurance Tests]

==Integration==
* [https://developer.mozilla.org/en-US/docs/Marionette/Marionette_JavaScript_Tools Marionette JS Tools]
* [https://github.com/mozilla-b2g/marionette-js-runner/blob/master/README.md Marionette JS Tools ReadMe]

==References==
* [https://fxos-perf.etherpad.mozilla.org/2013-07-17-kickoff Performance Automation Kickoff]
* [[/Regression_Detection_Requirements|Regression Detection Requirements]]

Firefox OS/Performance

2014-07-17T23:58:21Z

Mlee:

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Wander Costa, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org, '''[mailto:fxos-perf@mozilla.com fxos-perf@mozilla.com]'''
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Meetings=
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]'''
|-
|}

=Areas=

{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation_Testing|Automation & Testing]]''' || Hubert Figuière
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' || Wander Costa
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=== Regression Duty ===
Current areas of regression duty:
* Watch b2gperf start up times https://datazilla.mozilla.org/b2g
* Watch fxos-pert alerts. Currently, limited in scope to start up time regressions.
* Map of Gecko revisions reported by datazilla to their correct revision https://people.mozilla.org/~asasaki/vcs2vcs/gecko-dev/gecko-mapfile
* Get access to Jenkins. File a bug like [https://bugzilla.mozilla.org/show_bug.cgi?id=1036477 bug 1036477]

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]
* [http://charts.mozilla.org/ffos/blockers.html#responsibility=FxOS_Team&project=1.3,1.3T,1.4,2.0 Release Blocking Dashboard]

=Plans=

* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance/Triage

2014-07-16T19:42:46Z

Mlee: /* Blockers */ Ordered; top-down importance.

=Schedule=

* Triage: Wednesdays from 11am - 12pm PT
* Vidyo: [https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]
* IRC: irc://irc.mozilla.org:6697/#fxos-perf

=Queries=

==Blockers==
* Conventions
** ...'''?''' = blocker nominations = bugs nominated as something that should block that release.
** ...'''+''' = blockers = bugs accepted as being a release blocker.
** Blocking criteria can be found at: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines
** Additional blocking criteria for regressions.
*** Less than 50ms regression, not auto nom.
*** Between 50ms - 100ms regression, use your own discretion.
*** Greater than 100ms, auto nom.

* Queries
** Criteria:
*** Open Bugs
*** Products: Boot2Gecko Graveyard, Core, Firefox OS, Tech Evangelism, Testing, Toolkit
*** B2G blocking as below
*** Keywords: perf, mlk, footprint OR in the FxOS Performance component
** [http://mzl.la/1rrkXRr 2.0?]
** [http://mzl.la/Wi1sR7 2.0+ QC]
** [http://mzl.la/1rrkZst 2.0+]
** [http://mzl.la/1tRXdu4 1.4?]
** [http://mzl.la/1tRXjSB 1.4+]
** [http://mzl.la/1tRWNnv 1.3T+]




==Candidates==

* Criteria:
** Open Bugs
** Product: Firefox OS
** Not reviewed or tagged for Scrumbugs
** Perf issue according to one of following
*** Summary containing delay, perf, slow, sluggish
*** Keyword containing mlk, perf, footprint
*** In the FxOS Performance component

* [http://mzl.la/1rrm43H Untagged]
** Add '''perf''' keyword and Scrumbugs tags for all FxOS Performance issues.
** Add '''perf-reviewed''' whiteboard for bugs that are not FxOS Performance issues.
** Sort by ascending bug ID
** A not performance issue in the Firefox OS | Performance component should be moved elsewhere.

==Unprioritized Backlog==

* Criteria:
** Open Bugs
** Products: Boot2Gecko Graveyard, Core, Datazilla, Developer Engagement, Firefox OS, Marketplace, Powertool, Tech Evangelism, Testing
** Not prioritized
** Has Scrumbugs tags
** Keyword containing mlk, perf, footprint

* [http://mzl.la/1tS0729 All Open]
** Set Priority for all bugs covered in each triage session.
** Match [MemShrink:P?] priority when set unless bug is a release blocker.
** Close bugs that no longer reproduce or that no longer match product requirements.
** Identify blockers and relevancy.

=Keywords=

; footprint: Add to bugs regarding memory footprint performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; mlk: Add to bugs regarding memory leak/out-of-memory (OOM) performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; perf: Add to bugs covering regarding all types of performance or performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; regression: Add to bugs where a regression has occurred; previously working functionality has been broken or performance goal is no longer being met.
; regressionwindow-wanted: Add to bugs where the commit that caused the regression needs to be identified.
; qawanted: Add to bugs where performance needs to be verified (or re-verified) by QA. Specific instructions should always accompany this keyword.
This list is not comprehensive, and only includes keywords used very frequently by the FxOS Performance team during triage. For the full list of keywords and their descriptions see: https://bugzilla.mozilla.org/describekeywords.cgi

=Whiteboard Entries=

; [perf-reviewed]: Add to bugs that appear in an Untagged triage but should not be tracked by the FxOS Performance team. Excludes from future triages.
; [MemShrink]: Add to bugs that should be looked at by the [https://wiki.mozilla.org/Performance/MemShrink MemShrink team] responsible for maintaining efficient memory usage on FxOS.
This list is not comprehensive, and only includes whiteboard entries used very frequently by the FxOS Performance team during triage.

=Prioritization=

Prioritization of tasks is defined on a scale of decreasing priority from P1 to P5.

; [P1]: Any bug that is designated a blocker. Can also be used on tasks that we deem critical for our team to complete.
; [P2]: Bugs that are deemed important to solve but are not classified as blockers. Can also be used for critical engineering research tasks.
; [P3]: Lower priority bugs. Can also be used for common engineering research tasks.
; [P4]: Engineering research tasks for open schedules or down-time.
; [P5]: Dated bugs that have not been followed up on recently.

=Scrumbugs Tags=

Scrumbugs tags are added to the Whiteboard field in Bugzilla, but are actually directives to [http://scrumbu.gs Scrumbugs] for how to organize the bugs within sprints and backlogs.

The tags follow the format:

''[c=<component> p=<points> s=<sprint> u=<milestone>]''

Brackets are optional, but will help keep the tags from being accidentally mixed up with other whiteboard entries and not parsed by Scrumbugs. Spacing is significant; no spaces should be on either side of the equals. Order is not significant.

Tags may appear but be left empty, e.g. ''[c= p= s= u=]''. This will be sufficient to direct Scrumbugs to track the bug. Other valid values for tags are explained below.

Not all tags must appear, but our queries expect that any bug tracked by the FxOS Performance team will have the Component tag at minimum.

More information about Scrumbugs can be found on the [http://scrumbu.gs/help/ Scrumbugs Help Page]. Examples may be found on the [http://scrumbu.gs/t/fxos-dev-mlee/ FxOS Performance team's Scrumbugs page].

==c= Component==

The FxOS Performance team is generally less concerned about what module of code a bug affects (the Bugzilla component) than what kind of performance the bug impacts. Components are typically overridden via the Component tag to refer to particular user stories representing broad performance targets.

; (no value): use the component from Bugzilla
; automation: Automation-related
; benchmark: Performance Benchmarks
; boot: Boot Sequence (boot-2-homescreen)
; cpu: Excessive CPU usage
; devtools: Development Tools
; documentation: Documentation
; effect: Perception of cause & effect
; handeye: Hand-Eye coordination
; hardware: Hardware interfacing performance issues.
; memory: Memory leaks or footprint.
; power: Power Management
; profiling: Profiling tools
; progress: Perception of progress
; regression: Broken functionality that previously worked
; startup: Start up time optimizations
; uniformity: Frame Uniformity

More information may be found at [[../UserStories]].

==p= Points==

Point values are estimates of effort ranging from 1 to 5 set during Sprint Planning. They can be adjusted during a sprint cycle as their related issues become better understood. Point values are not usually set during triage.

{| border="1" cellpadding="5"
! Points !! Meaning
|-
! (no value)
| Unestimated
|-
! 1
| Clearly understood and trivial.
|-
! 2
| Clearly understood and non-complex.
|-
! 3
| Average, requiring investigation but not significant effort.
|-
! 4
| Difficult, requiring non-trivial investigation and implementation expected to take half or more of a sprint.
|-
! 5
| Very difficult, requiring significant investigation and implementation requiring an entire sprint.
|}

Issues requiring more time than a sprint cycle must be broken into smaller issues that can each be accomplished within a sprint.

==s= Sprint==

The Sprint tag is used to direct Scrumbugs to include the bug into a particular sprint.

The value of this tag, if set, refers to the name of a Scrumbugs sprint. FxOS Performance team sprints follow a date format ''YYYY.MM.DD'', where the date refers to the day the sprint ends in the Pacific Time timezone.

If the tag is included with an unset value, it has no effect.

This tag should not be used with a set value on open bugs, as it interferes with Scrumbugs' ability to migrate the bug from one sprint to the next when necessary. Once specified this way, the bug will always need to be manually managed within Scrumbugs, even if the tag is subsequently removed.

'''A value should only be set for this tag to insert an otherwise untracked bug into the current sprint after the bug has already been resolved'''.

==u= Milestone==

The Milestone tag is actually a repurposing of the Scrumbugs User tag. For the purposes of the FxOS Performance team, it is used to indicate the FxOS Release(s) and/or Device(s) for which the bug is targeted (e.g., ''1.2'', ''1.3'', ''tarako'', etc.)

The value, if set, will be reflected in the User column of [https://scrumbu.gs/p/fxos-perf/ Scrumbugs]. If the value is unset, the tag has no effect and the column will remain empty.

=Cc=

To Cc (Carbon Copy) the perf team in Bugzilla, use perf@fxos-perf.bugs as the address. People interested just need to watch that user in bugzilla. Don't Cc the team list.

Firefox OS/Performance/Triage

2014-07-16T19:40:15Z

Mlee: /* Blockers */ Added 2.0 QC FC Blockers

=Schedule=

* Triage: Wednesdays from 11am - 12pm PT
* Vidyo: [https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]
* IRC: irc://irc.mozilla.org:6697/#fxos-perf

=Queries=

==Blockers==
* Conventions
** ...'''?''' = blocker nominations = bugs nominated as something that should block that release.
** ...'''+''' = blockers = bugs accepted as being a release blocker.
** Blocking criteria can be found at: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines
** Additional blocking criteria for regressions.
*** Less than 50ms regression, not auto nom.
*** Between 50ms - 100ms regression, use your own discretion.
*** Greater than 100ms, auto nom.

* Queries
** Criteria:
*** Open Bugs
*** Products: Boot2Gecko Graveyard, Core, Firefox OS, Tech Evangelism, Testing, Toolkit
*** B2G blocking as below
*** Keywords: perf, mlk, footprint OR in the FxOS Performance component



** [http://mzl.la/1tRWNnv 1.3T+]
** [http://mzl.la/1tRXdu4 1.4?]
** [http://mzl.la/1tRXjSB 1.4+]
** [http://mzl.la/1rrkXRr 2.0?]
** [http://mzl.la/Wi1sR7 2.0+ QC]
** [http://mzl.la/1rrkZst 2.0+]

==Candidates==

* Criteria:
** Open Bugs
** Product: Firefox OS
** Not reviewed or tagged for Scrumbugs
** Perf issue according to one of following
*** Summary containing delay, perf, slow, sluggish
*** Keyword containing mlk, perf, footprint
*** In the FxOS Performance component

* [http://mzl.la/1rrm43H Untagged]
** Add '''perf''' keyword and Scrumbugs tags for all FxOS Performance issues.
** Add '''perf-reviewed''' whiteboard for bugs that are not FxOS Performance issues.
** Sort by ascending bug ID
** A not performance issue in the Firefox OS | Performance component should be moved elsewhere.

==Unprioritized Backlog==

* Criteria:
** Open Bugs
** Products: Boot2Gecko Graveyard, Core, Datazilla, Developer Engagement, Firefox OS, Marketplace, Powertool, Tech Evangelism, Testing
** Not prioritized
** Has Scrumbugs tags
** Keyword containing mlk, perf, footprint

* [http://mzl.la/1tS0729 All Open]
** Set Priority for all bugs covered in each triage session.
** Match [MemShrink:P?] priority when set unless bug is a release blocker.
** Close bugs that no longer reproduce or that no longer match product requirements.
** Identify blockers and relevancy.

=Keywords=

; footprint: Add to bugs regarding memory footprint performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; mlk: Add to bugs regarding memory leak/out-of-memory (OOM) performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; perf: Add to bugs covering regarding all types of performance or performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; regression: Add to bugs where a regression has occurred; previously working functionality has been broken or performance goal is no longer being met.
; regressionwindow-wanted: Add to bugs where the commit that caused the regression needs to be identified.
; qawanted: Add to bugs where performance needs to be verified (or re-verified) by QA. Specific instructions should always accompany this keyword.
This list is not comprehensive, and only includes keywords used very frequently by the FxOS Performance team during triage. For the full list of keywords and their descriptions see: https://bugzilla.mozilla.org/describekeywords.cgi

=Whiteboard Entries=

; [perf-reviewed]: Add to bugs that appear in an Untagged triage but should not be tracked by the FxOS Performance team. Excludes from future triages.
; [MemShrink]: Add to bugs that should be looked at by the [https://wiki.mozilla.org/Performance/MemShrink MemShrink team] responsible for maintaining efficient memory usage on FxOS.
This list is not comprehensive, and only includes whiteboard entries used very frequently by the FxOS Performance team during triage.

=Prioritization=

Prioritization of tasks is defined on a scale of decreasing priority from P1 to P5.

; [P1]: Any bug that is designated a blocker. Can also be used on tasks that we deem critical for our team to complete.
; [P2]: Bugs that are deemed important to solve but are not classified as blockers. Can also be used for critical engineering research tasks.
; [P3]: Lower priority bugs. Can also be used for common engineering research tasks.
; [P4]: Engineering research tasks for open schedules or down-time.
; [P5]: Dated bugs that have not been followed up on recently.

=Scrumbugs Tags=

Scrumbugs tags are added to the Whiteboard field in Bugzilla, but are actually directives to [http://scrumbu.gs Scrumbugs] for how to organize the bugs within sprints and backlogs.

The tags follow the format:

''[c=<component> p=<points> s=<sprint> u=<milestone>]''

Brackets are optional, but will help keep the tags from being accidentally mixed up with other whiteboard entries and not parsed by Scrumbugs. Spacing is significant; no spaces should be on either side of the equals. Order is not significant.

Tags may appear but be left empty, e.g. ''[c= p= s= u=]''. This will be sufficient to direct Scrumbugs to track the bug. Other valid values for tags are explained below.

Not all tags must appear, but our queries expect that any bug tracked by the FxOS Performance team will have the Component tag at minimum.

More information about Scrumbugs can be found on the [http://scrumbu.gs/help/ Scrumbugs Help Page]. Examples may be found on the [http://scrumbu.gs/t/fxos-dev-mlee/ FxOS Performance team's Scrumbugs page].

==c= Component==

The FxOS Performance team is generally less concerned about what module of code a bug affects (the Bugzilla component) than what kind of performance the bug impacts. Components are typically overridden via the Component tag to refer to particular user stories representing broad performance targets.

; (no value): use the component from Bugzilla
; automation: Automation-related
; benchmark: Performance Benchmarks
; boot: Boot Sequence (boot-2-homescreen)
; cpu: Excessive CPU usage
; devtools: Development Tools
; documentation: Documentation
; effect: Perception of cause & effect
; handeye: Hand-Eye coordination
; hardware: Hardware interfacing performance issues.
; memory: Memory leaks or footprint.
; power: Power Management
; profiling: Profiling tools
; progress: Perception of progress
; regression: Broken functionality that previously worked
; startup: Start up time optimizations
; uniformity: Frame Uniformity

More information may be found at [[../UserStories]].

==p= Points==

Point values are estimates of effort ranging from 1 to 5 set during Sprint Planning. They can be adjusted during a sprint cycle as their related issues become better understood. Point values are not usually set during triage.

{| border="1" cellpadding="5"
! Points !! Meaning
|-
! (no value)
| Unestimated
|-
! 1
| Clearly understood and trivial.
|-
! 2
| Clearly understood and non-complex.
|-
! 3
| Average, requiring investigation but not significant effort.
|-
! 4
| Difficult, requiring non-trivial investigation and implementation expected to take half or more of a sprint.
|-
! 5
| Very difficult, requiring significant investigation and implementation requiring an entire sprint.
|}

Issues requiring more time than a sprint cycle must be broken into smaller issues that can each be accomplished within a sprint.

==s= Sprint==

The Sprint tag is used to direct Scrumbugs to include the bug into a particular sprint.

The value of this tag, if set, refers to the name of a Scrumbugs sprint. FxOS Performance team sprints follow a date format ''YYYY.MM.DD'', where the date refers to the day the sprint ends in the Pacific Time timezone.

If the tag is included with an unset value, it has no effect.

This tag should not be used with a set value on open bugs, as it interferes with Scrumbugs' ability to migrate the bug from one sprint to the next when necessary. Once specified this way, the bug will always need to be manually managed within Scrumbugs, even if the tag is subsequently removed.

'''A value should only be set for this tag to insert an otherwise untracked bug into the current sprint after the bug has already been resolved'''.

==u= Milestone==

The Milestone tag is actually a repurposing of the Scrumbugs User tag. For the purposes of the FxOS Performance team, it is used to indicate the FxOS Release(s) and/or Device(s) for which the bug is targeted (e.g., ''1.2'', ''1.3'', ''tarako'', etc.)

The value, if set, will be reflected in the User column of [https://scrumbu.gs/p/fxos-perf/ Scrumbugs]. If the value is unset, the tag has no effect and the column will remain empty.

=Cc=

To Cc (Carbon Copy) the perf team in Bugzilla, use perf@fxos-perf.bugs as the address. People interested just need to watch that user in bugzilla. Don't Cc the team list.

Firefox OS/Performance/Release Acceptance

2014-07-15T21:18:45Z

Mlee: /* 2.0 */

= Criteria =

== Definitions ==

; Cold Launch Time : Milliseconds elapsed from the user-initiated launch of a not-already-in-memory app to the stable display of that app and its visible content.

; Reference Workload : A [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gaia/Hacking#Reference_Workloads standardized collection of application data] preloaded before the test is run.

''Note: All measurements are the median results calculated from multiple iterations of relevant tests. For example, Datazilla's App Cold Launch values are calculated from 30 such iterations.''

== 2.0 ==

* Reference Device: Flame
* Reference Workload: Light

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,communications/dialer,email%20FTU,fm,gallery,settings,video&app=settings&plot=median Cold Launch Time]
|-
| Browser || 1000 ms
|-
| Camera || 1000 ms
|-
| Contacts || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median Dialer] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median Email] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=fm&app=fm&plot=median FM Radio] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median Gallery] || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median Settings] || 1000 ms
|-
| SMS || 1000 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=video&app=video&plot=median Video] || 1000 ms
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 1.4 ==

* Reference Device: Buri/Hamachi
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! Cold Launch Time
|-
| Browser || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=browser&app=browser&plot=median No regression since 1.3]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=camera&app=camera&plot=median No regression since 1.3]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=contacts&app=contacts&plot=median No regression since 1.3]
|-
| Dialer || No regression since 1.3
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=email%20FTU&app=email%20FTU&plot=median No regression since 1.3]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=gallery&app=gallery&plot=median No regression since 1.3]
|-
| Marketplace || No regression since 1.3
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=settings&app=settings&plot=median No regression since 1.3]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=messages&app=messages&plot=median No regression since 1.3]
|}

== 1.3T ==

* Reference Device: Tarako

Acceptance for 1.3T will be determined by reviewing final performance results which will include [https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=90&test=cold_load_time&plot=median cold launch time].

Firefox OS/Performance

2014-07-14T17:48:08Z

Mlee: /* Team */

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Wander Lairson, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee + Jean Gong
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org, '''[mailto:fxos-perf@mozilla.com fxos-perf@mozilla.com]'''
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Meetings=
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]'''
|-
|}

=Areas=

{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation_Testing|Automation & Testing]]''' || Hubert Figuière
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' || Wander Lairson
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=== Regression Duty ===
Current areas of regression duty:
* Watch b2gperf start up times https://datazilla.mozilla.org/b2g
* Watch fxos-pert alerts. Currently, limited in scope to start up time regressions.
* Map of Gecko revisions reported by datazilla to their correct revision https://people.mozilla.org/~asasaki/vcs2vcs/gecko-dev/gecko-mapfile
* Get access to Jenkins. File a bug like [https://bugzilla.mozilla.org/show_bug.cgi?id=1036477 bug 1036477]

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]
* [http://charts.mozilla.org/ffos/blockers.html#responsibility=FxOS_Team&project=1.3,1.3T,1.4,2.0 Release Blocking Dashboard]

=Plans=

* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance

2014-07-14T17:47:38Z

Mlee: /* Areas */

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee + Jean Gong
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org, '''[mailto:fxos-perf@mozilla.com fxos-perf@mozilla.com]'''
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Meetings=
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]'''
|-
|}

=Areas=

{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation_Testing|Automation & Testing]]''' || Hubert Figuière
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' || Wander Lairson
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=== Regression Duty ===
Current areas of regression duty:
* Watch b2gperf start up times https://datazilla.mozilla.org/b2g
* Watch fxos-pert alerts. Currently, limited in scope to start up time regressions.
* Map of Gecko revisions reported by datazilla to their correct revision https://people.mozilla.org/~asasaki/vcs2vcs/gecko-dev/gecko-mapfile
* Get access to Jenkins. File a bug like [https://bugzilla.mozilla.org/show_bug.cgi?id=1036477 bug 1036477]

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]
* [http://charts.mozilla.org/ffos/blockers.html#responsibility=FxOS_Team&project=1.3,1.3T,1.4,2.0 Release Blocking Dashboard]

=Plans=

* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance

2014-07-11T01:46:07Z

Mlee:

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee + Jean Gong
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org, '''[mailto:fxos-perf@mozilla.com fxos-perf@mozilla.com]'''
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Meetings=
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]'''
|-
|}

=Areas=

{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation_Testing|Automation & Testing]]''' || Hubert Figuière
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' ||
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=== Regression Duty ===
Current areas of regression duty:
* Watch b2gperf start up times https://datazilla.mozilla.org/b2g
* Watch fxos-pert alerts. Currently, limited in scope to start up time regressions.
* Map of Gecko revisions reported by datazilla to their correct revision https://people.mozilla.org/~asasaki/vcs2vcs/gecko-dev/gecko-mapfile
* Get access to Jenkins. File a bug like [https://bugzilla.mozilla.org/show_bug.cgi?id=1036477 bug 1036477]

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]
* [http://charts.mozilla.org/ffos/blockers.html#responsibility=FxOS_Team&project=1.3,1.3T,1.4,2.0 Release Blocking Dashboard]

=Plans=

* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance/Release Acceptance

2014-07-10T22:39:55Z

Mlee: /* 2.0 */ Updated links to point to new 2.0 branch results

= Criteria =

== Definitions ==

; Cold Launch Time : Milliseconds elapsed from the user-initiated launch of a not-already-in-memory app to the stable display of that app and its visible content.

; Reference Workload : A [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gaia/Hacking#Reference_Workloads standardized collection of application data] preloaded before the test is run.

''Note: All measurements are the median results calculated from multiple iterations of relevant tests. For example, Datazilla's App Cold Launch values are calculated from 30 such iterations.''

== 2.0 ==

* Reference Device: Flame
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,communications/dialer,email%20FTU,fm,gallery,settings,video&app=settings&plot=median Cold Launch Time]
|-
| Browser || 1250 ms
|-
| Camera || 1250 ms
|-
| Contacts || 1250 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=communications/dialer&app=communications/dialer&plot=median Dialer] || 1250 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=email%20FTU&app=email%20FTU&plot=median Email] || 1250 ms

|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=gallery&app=gallery&plot=median Gallery] || 1250 ms
|-
| Marketplace || 1250 ms
|-
| [https://datazilla.mozilla.org/b2g/?branch=v2.0&device=flame&range=30&test=startup_%3E_moz-app-visually-complete&app_list=settings&app=settings&plot=median Settings] || 1250 ms
|-
| SMS || 1250 ms
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 1.4 ==

* Reference Device: Buri/Hamachi
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! Cold Launch Time
|-
| Browser || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=browser&app=browser&plot=median No regression since 1.3]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=camera&app=camera&plot=median No regression since 1.3]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=contacts&app=contacts&plot=median No regression since 1.3]
|-
| Dialer || No regression since 1.3
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=email%20FTU&app=email%20FTU&plot=median No regression since 1.3]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=gallery&app=gallery&plot=median No regression since 1.3]
|-
| Marketplace || No regression since 1.3
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=settings&app=settings&plot=median No regression since 1.3]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=messages&app=messages&plot=median No regression since 1.3]
|}

== 1.3T ==

* Reference Device: Tarako

Acceptance for 1.3T will be determined by reviewing final performance results which will include [https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=90&test=cold_load_time&plot=median cold launch time].

Firefox OS/Performance/Release Acceptance

2014-07-01T19:38:03Z

Mlee: /* 2.0 */

= Criteria =

== Definitions ==

; Cold Launch Time : Milliseconds elapsed from the user-initiated launch of a not-already-in-memory app to the stable display of that app and its visible content.

; Reference Workload : A [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gaia/Hacking#Reference_Workloads standardized collection of application data] preloaded before the test is run.

''Note: All measurements are the median results calculated from multiple iterations of relevant tests. For example, Datazilla's App Cold Launch values are calculated from 30 such iterations.''

== 2.0 ==

* Reference Device: Flame
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! [http://mzl.la/1qcMOqe Cold Launch Time]
|-
| Browser || 1250 ms
|-
| [http://mzl.la/1qIQehZ Camera] || 1250 ms
|-
| Contacts || 1250 ms
|-
| [http://mzl.la/1onCifZ Dialer] || 1250 ms
|-
| [http://mzl.la/1qeDT5r Email] || 1250 ms

|-
| [http://mzl.la/1ivaEWF Gallery] || 1250 ms
|-
| Marketplace || 1250 ms
|-
| [http://mzl.la/1pVeZYv Settings] || 1250 ms
|-
| SMS || 1250 ms
|}

''NOTE: These apps have been [https://bugzilla.mozilla.org/show_bug.cgi?id=996038#user_story_header instrumented] to emit events that support timing their [https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head launch states].''

== 1.4 ==

* Reference Device: Buri/Hamachi
* Reference Workload: Medium

{| class="wikitable"
|-
! Application !! Cold Launch Time
|-
| Browser || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=browser&app=browser&plot=median No regression since 1.3]
|-
| Camera || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=camera&app=camera&plot=median No regression since 1.3]
|-
| Contacts || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=contacts&app=contacts&plot=median No regression since 1.3]
|-
| Dialer || No regression since 1.3
|-
| Email || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=email%20FTU&app=email%20FTU&plot=median No regression since 1.3]
|-
| Gallery || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=gallery&app=gallery&plot=median No regression since 1.3]
|-
| Marketplace || No regression since 1.3
|-
| Settings || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=settings&app=settings&plot=median No regression since 1.3]
|-
| SMS || [https://datazilla.mozilla.org/b2g/?branch=v1.3&device=hamachi&range=90&test=cold_load_time&app_list=messages&app=messages&plot=median No regression since 1.3]
|}

== 1.3T ==

* Reference Device: Tarako

Acceptance for 1.3T will be determined by reviewing final performance results which will include [https://datazilla.mozilla.org/b2g/?branch=v1.3t&device=tarako&range=90&test=cold_load_time&plot=median cold launch time].

Firefox OS/Performance/Release Acceptance

2014-06-18T21:10:23Z

Mlee: /* 2.0 */ Added link to email Datazilla graph

Firefox OS/Performance/Release Acceptance

2014-06-13T23:26:09Z

Mlee: /* 2.0 */ Added links to new App Cold Launch Graphs on Datazilla

Firefox OS/Performance/Release Acceptance

2014-06-13T23:12:31Z

Mlee: /* Definitions */

Firefox OS/Performance/Investigating Alerts

2014-06-13T22:21:59Z

Mlee: /* Datazilla links */ Fixed the 'Bisecting Regressions' link

When you get an email from fxos-perf-alerts@mozilla.com, there is a good chance it is an automated email.

We have two types of automated alerts:
* Ingestion Alerts (we were expecting data and never received it)
* Regression Alerts (the values of the reported data have changed)

= Regression Alerts =

A regression alert has a Title in this format
'[ALERT][B2G] <testname> regressed by <-x.x> in <suite>'

example:

[[File:Alert_full_clean.png|600px]]

== Summary ==
The first part of the Alert is the score:

[[File:Alert_score.png|200px]]

The score can map directly to the confidence of the alert sustaining over time. The range is from 2-4 where 4 is .9999% sure. In the above example, we have a score of 3.32 which is .99932% confident this is a sustained regression.

The next section gives you direct links to the code that built B2G used for this test.

[[File:Alert_gaia_current.png|200px]]

The gaia revision is a link to github that shows the specific changes to gaia.

[[File:Alert_gecko_current.png|200px]]

The gecko revision is a link to github showing the current revision of gecko that we are using. {{bug|1010384}} tracks getting these links to work.

== Detailed Regressions ==
The last section of the alert is the details of the regression. For the given build, there could be many regressions found, we will list all of them in this section.

=== Device type ===
[[File:Alert_details_device.png|600px]]

We outline which device model is used. The example here is Tarako, Other values are Hamachi as well.

=== Suite ===
After the device we mention what suite showed a regression. In this example we have 'vsize' as the suite:
[[File:Alert_details_suite.png|600px]]

The suite will be from one of two harnesses:
* [[https://wiki.mozilla.org/FirefoxOS/Performance/Datazilla#Cold_Load_Time_and_FPS b2gperf]]
** possible values are: contacts, messages, settings, gallery, video, music, email, browser, homescreen, camera, phone, calendar, clock, fm radio, usage, template
* [[https://wiki.mozilla.org/FirefoxOS/Performance/Datazilla#Gaia_Tests make perf-test]]
** possible values are: pss, rss, system_pss, system_rss, system_uss, system_vsize, uss, vsize

=== Testname ===
Next is the testname that was run inside of the suite. In this example we have 'email_memory':
[[File:Alert_details_testname.png|600px]]

The test name is also dependent upon the suite and is from one of two harnesses:
* [[https://wiki.mozilla.org/FirefoxOS/Performance/Datazilla#Cold_Load_Time_and_FPS b2gperf]]
** possible values are: cold_load_time, fps
* [[https://wiki.mozilla.org/FirefoxOS/Performance/Datazilla#Gaia_Tests make perf-test]]
** possible values are: communications/contacts_memory, communications/dialer_memory, communications/ftu_memory, email_memory, settings_memory

=== Datazilla links ===
The next section is the Datazilla links, these are mostly self explanatory and for more information on what the view in Datazilla means, check out [[../Bisecting_Regressions|Bisecting Regressions]]:

[[File:Alert_datazilla_link.png|600px]]

=== Link to diff ===
After the links to Datazilla, we show a link to a diff of the Gaia repository (all changes from the previous test run to the current one):
[[File:Alert_github_diff.png|600px]]

=== Date of regression ===
The next field is the date. This is the date that the results were posted to Datazilla. Not the date we did the build or started the test run. Not the date that we detected the regression. Since the alerting system waits for future data, this date will be a few hours older than the email:
[[File:Alert_details_date.png|600px]]

=== Raw Numbers ===
The last section of the details is the raw numbers for Before, After, and Diff:
[[File:Alert_details_numbers.png|600px]]

* Before - the MEAN value of the previous 10 data points you see on the Datazila graph
* After - the MEAN value of the current data point + 9 future ones which are seen on the Datazilla graph
* Diff - After - Before

Firefox OS/Performance/Triage

2014-06-04T17:41:32Z

Mlee: /* c= Component */

=Schedule=

* Triage: Wednesdays from 11am - 12pm PT
* Vidyo: [https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]
* IRC: irc://irc.mozilla.org:6697/#fxos-perf

=Queries=

==Blockers==
* Conventions
** ...'''?''' = blocker nominations = bugs nominated as something that should block that release.
** ...'''+''' = blockers = bugs accepted as being a release blocker.
** Blocking criteria can be found at: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines

* Queries



** [http://mzl.la/1ieaOSq 1.3T+]
** [http://mzl.la/1hgZzua 1.4?]
** [http://mzl.la/ODfM2U 1.4+]
** [http://mzl.la/1eFcbr7 2.0?]
** [http://mzl.la/1hO0yhF 2.0+]

==Candidates==

* [http://mzl.la/1fI58AW Untagged]
** Add '''perf''' keyword and Scrumbugs tags for all FxOS Performance issues.
** Add '''perf-reviewed''' whiteboard for bugs that are not FxOS Performance issues.
** Sort by ascending bug ID

==Unprioritized Backlog==

* [http://mzl.la/1mJ78yU All Open]
** Set Priority for all bugs covered in each triage session.
** Match [MemShrink:P?] priority when set unless bug is a release blocker.
** Close bugs that no longer reproduce or that no longer match product requirements.
** Identify blockers and relevancy.

=Keywords=

; footprint: Add to bugs regarding memory footprint performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; mlk: Add to bugs regarding Out Of Memory (OOM) performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; perf: Add to bugs covering regarding all types of performance or performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; regression: Add to bugs where a regression has occurred; previously working functionality has been broken or performance goal is no longer being met.
; regressionwindow-wanted: Add to bugs where the commit that caused the regression needs to be identified.
; qawanted: Add to bugs where performance needs to be verified (or re-verified) by QA. Specific instructions should always accompany this keyword.
This list is not comprehensive, and only includes keywords used very frequently by the FxOS Performance team during triage. For the full list of keywords and their descriptions see: https://bugzilla.mozilla.org/describekeywords.cgi

=Whiteboard Entries=

; [perf-reviewed]: Add to bugs that appear in an Untagged triage but should not be tracked by the FxOS Performance team. Excludes from future triages.
; [MemShrink]: Add to bugs that should be looked at by the [https://wiki.mozilla.org/Performance/MemShrink MemShrink team] responsible for maintaining efficient memory usage on FxOS.
This list is not comprehensive, and only includes whiteboard entries used very frequently by the FxOS Performance team during triage.

=Prioritization=

Prioritization of tasks is defined on a scale of decreasing priority from P1 to P5.

; [P1]: Any bug that is designated a blocker. Can also be used on tasks that we deem critical for our team to complete.
; [P2]: Bugs that are deemed important to solve but are not classified as blockers. Can also be used for critical engineering research tasks.
; [P3]: Lower priority bugs. Can also be used for common engineering research tasks.
; [P4]: Engineering research tasks for open schedules or down-time.
; [P5]: Dated bugs that have not been followed up on recently.

=Scrumbugs Tags=

Scrumbugs tags are added to the Whiteboard field in Bugzilla, but are actually directives to [http://scrumbu.gs Scrumbugs] for how to organize the bugs within sprints and backlogs.

The tags follow the format:

''[c=<component> p=<points> s=<sprint> u=<milestone>]''

Brackets are optional, but will help keep the tags from being accidentally mixed up with other whiteboard entries and not parsed by Scrumbugs. Spacing is significant; no spaces should be on either side of the equals. Order is not significant.

Tags may appear but be left empty, e.g. ''[c= p= s= u=]''. This will be sufficient to direct Scrumbugs to track the bug. Other valid values for tags are explained below.

Not all tags must appear, but our queries expect that any bug tracked by the FxOS Performance team will have the Component tag at minimum.

More information about Scrumbugs can be found on the [http://scrumbu.gs/help/ Scrumbugs Help Page]. Examples may be found on the [http://scrumbu.gs/t/fxos-dev-mlee/ FxOS Performance team's Scrumbugs page].

==c= Component==

The FxOS Performance team is generally less concerned about what module of code a bug affects (the Bugzilla component) than what kind of performance the bug impacts. Components are typically overridden via the Component tag to refer to particular user stories representing broad performance targets.

; (no value): use the component from Bugzilla
; automation: Automation-related
; benchmark: Performance Benchmarks
; boot: Boot Sequence (boot-2-homescreen)
; devtools: Development Tools
; documentation: Documentation
; effect: Perception of cause & effect
; handeye: Hand-Eye coordination
; hardware: Hardware interfacing performance issues.
; memory: Memory leaks or footprint.
; power: Power Management
; profiling: Profiling tools
; progress: Perception of progress
; regression: Broken functionality that previously worked
; uniformity: Frame Uniformity

More information may be found at [[../UserStories]].

==p= Points==

Point values are estimates of effort ranging from 1 to 5 set during Sprint Planning. They can be adjusted during a sprint cycle as their related issues become better understood. Point values are not usually set during triage.

{| border="1" cellpadding="5"
! Points !! Meaning
|-
! (no value)
| Unestimated
|-
! 1
| Clearly understood and trivial.
|-
! 2
| Clearly understood and non-complex.
|-
! 3
| Average, requiring investigation but not significant effort.
|-
! 4
| Difficult, requiring non-trivial investigation and implementation expected to take half or more of a sprint.
|-
! 5
| Very difficult, requiring significant investigation and implementation requiring an entire sprint.
|}

Issues requiring more time than a sprint cycle must be broken into smaller issues that can each be accomplished within a sprint.

==s= Sprint==

The Sprint tag is used to direct Scrumbugs to include the bug into a particular sprint.

The value of this tag, if set, refers to the name of a Scrumbugs sprint. FxOS Performance team sprints follow a date format ''YYYY.MM.DD'', where the date refers to the day the sprint ends in the Pacific Time timezone.

If the tag is included with an unset value, it has no effect.

This tag should not be used with a set value on open bugs, as it interferes with Scrumbugs' ability to migrate the bug from one sprint to the next when necessary. Once specified this way, the bug will always need to be manually managed within Scrumbugs, even if the tag is subsequently removed.

'''A value should only be set for this tag to insert an otherwise untracked bug into the current sprint after the bug has already been resolved'''.

==u= Milestone==

The Milestone tag is actually a repurposing of the Scrumbugs User tag. For the purposes of the FxOS Performance team, it is used to indicate the FxOS Release(s) and/or Device(s) for which the bug is targeted (e.g., ''1.2'', ''1.3'', ''tarako'', etc.)

The value, if set, will be reflected in the User column of [https://scrumbu.gs/p/fxos-perf/ Scrumbugs]. If the value is unset, the tag has no effect and the column will remain empty.

=Cc=

To Cc (Carbon Copy) the perf team in Bugzilla, use perf@fxos-perf.bugs as the address. People interested just need to watch that user in bugzilla. Don't Cc the team list.

Firefox OS/Performance

2014-05-29T21:57:47Z

Mlee: /* Meetings */ Added link to 2014 Q3 Paris Workweek

<big>Mozilla's program for advancing Firefox OS performance.</big>

=Team=
{| class="wikitable fullwidth-table"
| Engineering Manager || Mike Lee
|-
| Engineering || Jon Hylands, Hubert Figuière, David Huseby, Mason Chang, Eli Perelman, Jonathan Bailey (Intern)
|-
| Quality Assurance || Geo Mealer
|-
| Product Management || Ravi Dandu
|-
| Program Management || Mike Lee + Jean Gong
|-
| User Experience || Gordon Brander
|-
| Contact Info || '''[ircs://irc.mozilla.org:6697/fxos-perf #fxos-perf]''' on irc.mozilla.org, '''[mailto:fxos-perf@mozilla.com fxos-perf@mozilla.com]'''
|-
| Wiki || https://wiki.mozilla.org/FirefoxOS/Performance
|-
|}

=Areas=

{| class="wikitable fullwidth-table"
| '''Area''' || '''Lead'''
|-
| '''[[/Automation_Testing|Automation & Testing]]''' || Hubert Figuière
|-
| '''[[/Graphics|Graphics]]''' || Mason Chang
|-
| '''[[/Memory|Memory]]''' ||
|-
| '''[[/Power|Power]]''' || Jon Hylands
|-
| '''[[/Responsiveness|Responsiveness]]''' || Eli Perelman
|-
| '''[[/Tools|Tools]]''' || David Huseby
|-
|}

=Meetings=
{| class="wikitable fullwidth-table"
| Timezones || United States (PT, CT, & ET), Canada (ET)
|-
| Calendar (CalDAV) || https://mail.mozilla.com/dav/mozillacalendar@mozilla.com/FxOS%20Performance
|-
| [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Tuesdays @ 1pm PT & Fridays @ 11am PT
|-
| [[/Triage/|Bug Triages]] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: Wednesdays @ 11am PT
|-
| [http://scrumbu.gs/p/fxos-perf/ Sprint Planning] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: 10am PT on last Friday of each sprint.
|-
| [https://fxos-perf.etherpad.mozilla.org/6 Meet-Ups & Workweeks] || '''[https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]''' Vidyo Room: '''[https://fxos-perf.etherpad.mozilla.org/workweek2014q3 Paris: 2014.07.21 - 25]'''
|-
|}

=Dashboards=
* [https://datazilla.mozilla.org/b2g/ Datazilla: Instrumented Apps]
* [http://eideticker.mozilla.org/b2g/ Eideticker: Automated Camera Measurement]

=Plans=

* [https://fxos-perf.etherpad.mozilla.org/ Etherpads]
* [[/Release_Acceptance/|Release Criteria]]
* [https://docs.google.com/a/mozilla.com/document/d/1_8RehppYplSpYZZtALxNTstj8l-BoustidBMaxuazo4/edit Roadmap]
* [http://scrumbu.gs/p/fxos-perf/ Sprints]
* [https://fxos-perf.etherpad.mozilla.org/2 Stand-ups]
* [[TPEPerformance|Taipei]]
* [[/Triage/]]
* [[/UserStories|User Stories]]

=Progress=
<bugzilla type="count" display="bar">
{
"product": "Firefox OS",
"keywords":"perf",
"keywords_type":"contains",
"whiteboard":"c=",
"whiteboard_type":"contains",
"x_axis_field":"status"
}
</bugzilla>

=Project Ideas=
* '''Gonk/Gecko'''
** [[/Boot Sequence Optimization|Boot Sequence Optimization]] (taken! jbailey's 2014 summer intern project)
** [[/IndexDB IO Optimization|IndexDB IO Optimization]]
* '''Graphics'''
** [[/Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler|Graphics Pipeline Instrumentation and Integration into the Cleopatra Profiler]]
** [[/Graphics Performance Automation|Graphics Performance Automation (checkerboarding detection, datazilla integration, micro benchmarks)]]
* '''Tools'''
** [[/Adding Features to Datazilla|Adding Features to Datazilla]]
** [[/Adding Features to Scrumbugs|Adding Features to Scrumbugs]]
** [[/Automating Datazilla Developer Setup|Automating Datazilla Developer Setup]]
** [[/Automating Firefox OS Developer Setup|Automating Firefox OS Developer Setup]]
** [[/Automating Scrumbugz Developer Setup|Automating Scrumbugz Developer Setup]]

=References=
==[[FirefoxOS|Firefox OS]]==
* '''Architecture'''
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture Overview]
** [[Modules/All#FirefoxOS|Modules]]
** [https://github.com/sotaroikeda/firefox-diagrams/wiki/Firefox-Diagrams Diagrams]
** [https://docs.google.com/a/mozilla.com/drawings/d/18DnhTgQBK3M0KBeLGJkWW1hfiYBB6GgTmfdbUnT2SLs/edit Gaia]
* '''[[B2G/Roadmap|Roadmap]]'''
* '''[[Release_Management/B2G_Landing|Schedule]]'''
** [[FirefoxOS/Tarako|Tarako]]
* '''Docs'''
** [[/App_Performance_Validation|App Performance Validation]]
** [https://etherpad.mozilla.org/b2g-ateam-perf A*Team Performance Tools]
** [https://developer.mozilla.org/en-US/Firefox_OS/Platform/Architecture#Firefox_OS_bootup_procedure Boot Sequence]
** [[FirefoxOS/Geolocation|GPS]]
** [[Marketplace/Performance_optimization|Marketplace Performance]]
** [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Performance Performance Tips]
** [https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks QA Tips & Tricks]
** [[/Upstreaming Kernel Changes to Geeksphone|Upstreaming Kernel Changes to Geeksphone]]
** [[/Investigating_Alerts|Investigating Automated Alerts]]
*** [[/Bisecting_Regressions|Bisecting Regression]]
** [[/Using Docker to Ease Debugging Firefox OS|Using Docker to Ease Debugging Firefox OS]]

==Mozilla==
* [https://www.mozilla.org/hacking/commit-access-policy/ Mozilla Commit Access Policy]
* [http://www.mozilla.org/hacking/committer/ Mozilla Commit Process]

==Articles==
* CSS
** [https://medium.com/web-design-technique/6b51bf53743a Blend Modes]
** [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS Efficient CSS]
* [http://json.org JSON]
* Lists
** [http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html Implementing Virtual Lists]
** [http://people.mozilla.org/~roc/virtual-list-demo.html Virtual List Demo]
* [http://stevesouders.com/ Steve Souders' Web Performance]

Firefox OS/Performance/Triage

2014-05-28T22:31:31Z

Mlee: /* Blockers */

=Schedule=

* Triage: Wednesdays from 11am - 12pm PT
* Vidyo: [https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]
* IRC: irc://irc.mozilla.org:6697/#fxos-perf

=Queries=

==Blockers==
* Conventions
** ...'''?''' = blocker nominations = bugs nominated as something that should block that release.
** ...'''+''' = blockers = bugs accepted as being a release blocker.
** Blocking criteria can be found at: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines

* Queries



** [http://mzl.la/1ieaOSq 1.3T+]
** [http://mzl.la/1hgZzua 1.4?]
** [http://mzl.la/ODfM2U 1.4+]
** [http://mzl.la/1eFcbr7 2.0?]
** [http://mzl.la/1hO0yhF 2.0+]

==Candidates==

* [http://mzl.la/1fI58AW Untagged]
** Add '''perf''' keyword and Scrumbugs tags for all FxOS Performance issues.
** Add '''perf-reviewed''' whiteboard for bugs that are not FxOS Performance issues.
** Sort by ascending bug ID

==Unprioritized Backlog==

* [http://mzl.la/1mJ78yU All Open]
** Set Priority for all bugs covered in each triage session.
** Match [MemShrink:P?] priority when set unless bug is a release blocker.
** Close bugs that no longer reproduce or that no longer match product requirements.
** Identify blockers and relevancy.

=Keywords=

; footprint: Add to bugs regarding memory footprint performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; mlk: Add to bugs regarding Out Of Memory (OOM) performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; perf: Add to bugs covering regarding all types of performance or performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; regression: Add to bugs where a regression has occurred; previously working functionality has been broken or performance goal is no longer being met.
; regressionwindow-wanted: Add to bugs where the commit that caused the regression needs to be identified.
; qawanted: Add to bugs where performance needs to be verified (or re-verified) by QA. Specific instructions should always accompany this keyword.
This list is not comprehensive, and only includes keywords used very frequently by the FxOS Performance team during triage. For the full list of keywords and their descriptions see: https://bugzilla.mozilla.org/describekeywords.cgi

=Whiteboard Entries=

; [perf-reviewed]: Add to bugs that appear in an Untagged triage but should not be tracked by the FxOS Performance team. Excludes from future triages.
; [MemShrink]: Add to bugs that should be looked at by the [https://wiki.mozilla.org/Performance/MemShrink MemShrink team] responsible for maintaining efficient memory usage on FxOS.
This list is not comprehensive, and only includes whiteboard entries used very frequently by the FxOS Performance team during triage.

=Prioritization=

Prioritization of tasks is defined on a scale of decreasing priority from P1 to P5.

; [P1]: Any bug that is designated a blocker. Can also be used on tasks that we deem critical for our team to complete.
; [P2]: Bugs that are deemed important to solve but are not classified as blockers. Can also be used for critical engineering research tasks.
; [P3]: Lower priority bugs. Can also be used for common engineering research tasks.
; [P4]: Engineering research tasks for open schedules or down-time.
; [P5]: Dated bugs that have not been followed up on recently.

=Scrumbugs Tags=

Scrumbugs tags are added to the Whiteboard field in Bugzilla, but are actually directives to [http://scrumbu.gs Scrumbugs] for how to organize the bugs within sprints and backlogs.

The tags follow the format:

''[c=<component> p=<points> s=<sprint> u=<milestone>]''

Brackets are optional, but will help keep the tags from being accidentally mixed up with other whiteboard entries and not parsed by Scrumbugs. Spacing is significant; no spaces should be on either side of the equals. Order is not significant.

Tags may appear but be left empty, e.g. ''[c= p= s= u=]''. This will be sufficient to direct Scrumbugs to track the bug. Other valid values for tags are explained below.

Not all tags must appear, but our queries expect that any bug tracked by the FxOS Performance team will have the Component tag at minimum.

More information about Scrumbugs can be found on the [http://scrumbu.gs/help/ Scrumbugs Help Page]. Examples may be found on the [http://scrumbu.gs/t/fxos-dev-mlee/ FxOS Performance team's Scrumbugs page].

==c= Component==

The FxOS Performance team is generally less concerned about what module of code a bug affects (the Bugzilla component) than what kind of performance the bug impacts. Components are typically overridden via the Component tag to refer to particular user stories representing broad performance targets.

; (no value): use the component from Bugzilla
; automation: Automation-related
; benchmark: Performance Benchmarks
; boot: Boot Sequence (boot-2-homescreen)
; devtools: Development Tools
; documentation: Documentation
; effect: Perception of cause & effect
; handeye: Hand-Eye coordination
; hardware: Hardware interfacing performance issues.
; memory: Memory leaks or footprint.
; power: Power Management
; profiling: Profiling tools
; progress: Perception of progress
; uniformity: Frame Uniformity

More information may be found at [[../UserStories]].

==p= Points==

Point values are estimates of effort ranging from 1 to 5 set during Sprint Planning. They can be adjusted during a sprint cycle as their related issues become better understood. Point values are not usually set during triage.

{| border="1" cellpadding="5"
! Points !! Meaning
|-
! (no value)
| Unestimated
|-
! 1
| Clearly understood and trivial.
|-
! 2
| Clearly understood and non-complex.
|-
! 3
| Average, requiring investigation but not significant effort.
|-
! 4
| Difficult, requiring non-trivial investigation and implementation expected to take half or more of a sprint.
|-
! 5
| Very difficult, requiring significant investigation and implementation requiring an entire sprint.
|}

Issues requiring more time than a sprint cycle must be broken into smaller issues that can each be accomplished within a sprint.

==s= Sprint==

The Sprint tag is used to direct Scrumbugs to include the bug into a particular sprint.

The value of this tag, if set, refers to the name of a Scrumbugs sprint. FxOS Performance team sprints follow a date format ''YYYY.MM.DD'', where the date refers to the day the sprint ends in the Pacific Time timezone.

If the tag is included with an unset value, it has no effect.

This tag should not be used with a set value on open bugs, as it interferes with Scrumbugs' ability to migrate the bug from one sprint to the next when necessary. Once specified this way, the bug will always need to be manually managed within Scrumbugs, even if the tag is subsequently removed.

'''A value should only be set for this tag to insert an otherwise untracked bug into the current sprint after the bug has already been resolved'''.

==u= Milestone==

The Milestone tag is actually a repurposing of the Scrumbugs User tag. For the purposes of the FxOS Performance team, it is used to indicate the FxOS Release(s) and/or Device(s) for which the bug is targeted (e.g., ''1.2'', ''1.3'', ''tarako'', etc.)

The value, if set, will be reflected in the User column of [https://scrumbu.gs/p/fxos-perf/ Scrumbugs]. If the value is unset, the tag has no effect and the column will remain empty.

=Cc=

To Cc (Carbon Copy) the perf team in Bugzilla, use perf@fxos-perf.bugs as the address. People interested just need to watch that user in bugzilla. Don't Cc the team list.

Platform/2014-05-20

2014-05-20T23:14:47Z

Mlee: /* Firefox OS Performance (mlee) */

[[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous week]] | [[Platform|index]] | [[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]

<div class="h-event vevent">
'''Engineering Meeting Details'''
* Tuesday {{#time: Y-m-d | {{SUBPAGENAME}} }} - 11:00 am <abbr class="value" title="-0800">Pacific Standard Time</abbr>
{{conf|98411}}
* [https://v.mozilla.com/flex.html?roomdirect.html&key=T2v8Pi8WuTRc Engineering Vidyo Room] / [https://air.mozilla.org/ Air Mozilla] / MTV Warp Core / TOR Finch / SFO Warfield / PDX Hair of the Dog
* join irc.mozilla.org [irc://irc.mozilla.org/planning #planning] for back channel
</div>

==Need To Know==
(Release and system issues that may impact engineering this week.)

===Notices/Schedule (lsblakk/sylvestre)===
('''READ-ONLY''')
* 30.0b6 Desktop & Mobile going to build this morning, shipping Wednesday
* We're in week 4 of beta, all tracked bugs should be assigned and we're taking less risky/forward fixes - more focus on stability, security fixes and where necessary - backouts

{| class="wikitable" style="color:green; background-color:#ffffcc;" cellpadding="10" padding="5"
|-
|colspan="2"|<big>Next Merge:</big> '''{{FIREFOX_MERGE_DATE}}'''
|colspan="2"|<big>Next Release:</big> '''{{FIREFOX_SHIP_DATE}}'''
|-
!colspan="4" style="color:black;"|Trains
|-
|Central: {{CENTRAL_VERSION}}
|Aurora: {{AURORA_VERSION}}
|Beta: {{BETA_VERSION}}
|Release: {{RELEASE_VERSION}}
|}

===Build Changes (gps)===
(Build changes of which engineers should be aware.)



===RelEng (catlee)===
(Repo, test, and other information for engineers from the release engineering team.)



===Upcoming Outages/Upgrades===
(System outages/upgrades and tree closures that impact engineering.)
* Possibility of emergency downtime Fri 1800 PT - worst case 30 min to fix some networking issues. If any reason to defer, contact hwine prior to Fri

==Quality Programs==
(An opportunity to hear about status with the various quality programs that do not have a formal team structure.)

===OrangeFactor (ryanvm)===
{{readonly}}
* Past week's OrangeFactor: [http://brasstacks.mozilla.com/orangefactor/ 7.61] (Previous Week: 8.84).
* Thanks to Mark Hammond for fixing a whole class of failures in the browser_thumbnails mochitests ({{bug|916497}} et al).
* Thanks to Joel Maher for fixing a 1-year old Windows dromaeojs hang ({{bug|872788}}).
* {{bug|870205}} (discussed last week) remains a top orange.
* 16 intermittent failures fixed in the last week - [https://bugzilla.mozilla.org/buglist.cgi?keywords_type=allwords&keywords=intermittent-failure%2C%20&resolution=FIXED&o1=greaterthan&v1=2014-05-13&f1=cf_last_resolved&query_format=advanced&list_id=10249433 List] - Thanks!.

===CritSmash (dbolter)===
* (Readonly) Risk still not trending well. Will shout from the hill tops next week if necessary.

===MemShrink (njn)===
* No update.

===Stability (kairo/bsmedberg)===
* [http://arewestableyet.com/ Overall numbers] look good except for Nightly, which is missing correct ADI data.
* ADI data for Nightly is being collected in different manner than before, we will get back to having numbers by the end of this week.

==Team Stand-ups==
(In <2 mins, what did your team accomplish last week, on what is your team working on this week, and on what, if anything, is your team blocked? No questions during the stand-ups. All questions should be asked during the roundtable.)

===Accessibility (dbolter)===



===App Tools (prouget)===



===B2G Services (dougt)===



===Developer Tools (robcee)===



===DOM (jst/overholt)===



===Electrolysis (e10s) (blassey)===


* {{bug|996785}} - Bidirectional CPOWs to improve add-on compat.
* {{bug|913249}} - OMTC for Windows landed (but was backed out).
* {{bug|1004745}} - "zombie" joins us for his GSoC project to make Jetpack Add-on SDK e10s-compatible.
* Many crash fixes.

===Firefox Desktop (gavin)===



===Firefox Mobile (mfinkle/blassey)===


====Work In Progress====
*Firefox Hub ([https://bugzilla.mozilla.org/show_bug.cgi?id=817716 817716],[https://bugzilla.mozilla.org/show_bug.cgi?id=1004153 1004153],[https://bugzilla.mozilla.org/show_bug.cgi?id=1007408 1007408],[https://bugzilla.mozilla.org/show_bug.cgi?id=965452 965452],[https://bugzilla.mozilla.org/show_bug.cgi?id=701725 701725])
*Sync ([https://bugzilla.mozilla.org/show_bug.cgi?id=1003877 1003877],[https://bugzilla.mozilla.org/show_bug.cgi?id=1005072 1005072],[https://bugzilla.mozilla.org/show_bug.cgi?id=891600 891600],[https://bugzilla.mozilla.org/show_bug.cgi?id=965924 965924])
You can find more on upcoming feature plans in the[[https://wiki.mozilla.org/Mobile/Roadmap| roadmap]]
====Landings====
=====Nightly ({{CENTRAL_VERSION}})=====
*Add support for connecting to HTTP proxy over HTTPS ([https://bugzilla.mozilla.org/show_bug.cgi?id=378637 Bug 378637])
*Unify removal behavior for bookmark-history-readinglist items from Home items ([https://bugzilla.mozilla.org/show_bug.cgi?id=921136 Bug 921136])
*Text selection keyboard shortcuts not working ([https://bugzilla.mozilla.org/show_bug.cgi?id=993261 Bug 993261])
*Zoom level mangled after restoring session ([https://bugzilla.mozilla.org/show_bug.cgi?id=1002426 Bug 1002426])

===Firefox OS Communications (scravag)===



===Firefox OS Devices/Porting (ericchou)===
{{readonly}}
* Device porting (Gonk team)
** Porting Summary
*** [http://goo.gl/tHXAE9 Flame]
*** [http://goo.gl/knKzFq Vixen]
*** [http://goo.gl/mjd0ay Tarako]: Released a build for OEM on 5/20.
*** [http://goo.gl/9cCPxs Dolphin]: SPRD PTR0 (the first test run).
** On-site support
*** SPRD Shanghai
**** Kai-zhen Li 5/9-5/20

* Bluetooth (members: Shawn Huang, Ben Tian, Jamin Liu, Jocelyn Liu)
** WebBluetooth API refinement has started. Ben and Jocelyn will dedicate on it.
** NFC integration issues ({{Bug|1009459}}, {{Bug|1009470}})
** 1.4+ issues: {{Bug|997962}} and {{Bug|1011110}}. Both are still under investigation.

* Media Playback (members: Bruce Sun, Blake Wu, Star Cheng)
** {{Bug|941302}} - PlatformDecoderModule for Firefox OS - WIP
** {{Bug|904177}} - Integrate MediaCodec into gecko for media playback - WIP
*** First step, tried to make mp3 playback work.
** {{Bug|1007552}} - [Madai] 'publicnotification' channel should be fixed for camera shutter - WIP
*** Gonk patch provided.

* Device Storage & Stability (members: Alan Huang, Alphan Chen)
** The first version of FeatureDetection API has landed, followup bug got r+. ({{bug|983502}}, {{bug|996996}})

===Firefox OS Media Apps (hema)===

{{readonly}}
* Continuing to work on blocking bugs for 1.3T, 1.4, 2.0
* Performance optimizations on Music/Gallery for Tarako
* Wrapping up Ringtones User Stories (in 2.0 we will have the basic features in)
* Landed Camera Touch Focus on master -- please test and file bugs
* Working on Camera Face Detection feature, targeting to land this in current sprint.

===Firefox OS Media Recording (cjku)===

{{readonly}}
*{{Bug|987529}} - Implement Vsync dispatch pipeline
*{{Bug|989945}} - [B2G][WebRTC] long video lag when using H.264 codec.
*{{Bug|981153}} - Intermittent test_seek.html | Test timed out.
*{{bug|983489}} - Crash on nsIAppStartup.quit()
*{{Bug|997367}} - Crash at CorssProcessParent

===[https://wiki.mozilla.org/FirefoxOS/Performance Firefox OS Performance (mlee)]===

{{readonly}}

'''[https://scrumbu.gs/t/fxos-dev-mlee/ Sprints]'''
* [https://scrumbu.gs/t/fxos-dev-mlee/2014.05.23/ 2014.05.23 - Current]
* [https://scrumbu.gs/t/fxos-dev-mlee/2014.05.23.t/ 2014.05.23 - Currently Tracking]

'''Updates'''
* '''Responsiveness: Eli Perelman'''
** Launch states {{bug|996038}} design finalized and implementation in progress.

* '''Power Consumption: Jon Hylands'''
** Power Performance Server in development

===Firefox OS Productivity (doliver)===



===Firefox OS Radio/WiFi/GPS (kenhkchang)===



===Firefox OS Systems - Front End (gwagner)===



===Firefox OS Systems - Platform (timdream)===



===GFX (milan)===

* OMTC desktop
** Windows landed, backed out, relanding (mostly needed to change timeout values in tests)
** Linux: getting close
* Skia
** Following up on reftests failures. Currently in gradients - not just a fuzzing issue
* APZ
** Flywheel scrolling seems to be OK
** Putting in a developer pref for overscroll effect so that UX can test it and see if the design feels right
* New or unplanned things
** Flame support for 1.3 (and somewhat less of a surprise, for 1.4)
** FxOS 1.4 games performance
** Intern heading for Toronto ended up in Mountain View (no fault of Mozilla) - rejigging some plans to help Walter with local support/tasks.

===Identity (jedp)===



===JS (naveed)===

{{readonly}}

* Compiler (JIT)
** {{bug|1010775}}: Refactored assembler code to pass some small classes by value instead of by reference

* Garbage Collection
** {{bug|933313}}: PJS: Integrate with generational garbage collection
** {{bug|969012}}: Investigate and fix a raytrace regression from prior landing.
** {{bug|1008473}}: Work begun on semi-space GC

* Front End and Other
** {{bug|998392}} {{bug|1008590}} {{bug|1011693}}: ASCII/Latin1 strings support in JS - begun and ongoing
** {{bug|745324}}: our ClampDoubleToUint8 doesn't follow the algorithm stated in last ES6 spec (fix ready for the interpreter)
** Nick Nethercote blogged about AdBlock Plus memory usage in Firefox: https://blog.mozilla.org/nnethercote/2014/05/14/adblock-pluss-effect-on-firefoxs-memory-usage/

===Layout (jet/dbaron)===
{{readonly}}
* W3C CSS Working Group F2F Meetings this week
** http://wiki.csswg.org/planning/seoul-2014
* Notable Bug Fixes:
**{{Bug|964646}} - Add tests for async CSS Animations (OMTA)
**{{Bug|1008787}} - Plugins should be clipped to the size layout expects them to be
**{{Bug|1009478}} - Make LayerActivity properties survive across reframes of an element
**{{Bug|1005660}} - Add an "early freeze" step, to freeze flex items that clearly can't grow (or shrink, if we're shrinking).
**{{Bug|1010470}} - Use :disabled pseudoclass instead of [disabled] attribute-selector to style disabled form controls on B2G & Android.
**{{Bug|1001233}} - convert bullet frame's margin to the block frame's writing mode when positioning bullet.
**{{Bug|992100}} - mask out complex-script codepoints in fonts that lack the necessary layout tables.
**{{Bug|1009263}} - Add nsCheapSets::Clear() method that removes all entries and return it to minimal size in terms of memory use.
**{{Bug|1008969}} - [css-grid] add nsGridContainerFrame::Reflow and a few grid related nsHTMLReflowState additions
**{{Bug|1000423}} - position: fixed elements are misplaced
**{{Bug|916315}} - Enable CSS sticky positioning in release desktop builds
**{{Bug|590790}} - Add memory reporter for VectorImage's SVGDocumentWrapper's document
**{{Bug|1004327}} - input type=number limited to 3 digits of precision

===Media (mreavy)===

{{readonly}}
* WebRTC Interim meeting in Washington DC this week
* H264 SDP and packetization code progressing; likely will land soon in support of B2G HW codecs and OpenH264
* Investigating a significant regression in call connections in WebRTC (possible ICE rate-limiting issue)
** If confirmed, will ask for uplift of a fix to Beta
* Media Capture working group (MediaStreams, getUserMedia()) likes standardizing mozCaptureStream/mozCaptureStreamUntilEnded, and extending to canvases

===Necko (dougt/jduell)===



* New HTTP cache has landed!
** http://www.janbambas.cz/new-firefox-http-cache-enabled/
** gets rid of largest sources of jank in the browser: other than some startup jank we appear to have no more janks that are longer than 100ms, even on very slow disks. (note: Honza's number's are with a patch that disabled 5 sources of startup jank)
** 1st hit (uncached) loads are now much faster, since we delay writing to cache.
** Cache no longer disappears whenever we have "unclean" shutdown (which was ~10-20% of the time)
** We still have some memory consumption issues to fix on mobile ({{bug|1013333}}, and B2G/mobile folks may want to help us decide what amount of RAM cache, etc we should use.
* TLS proxying (ie. TLS connection to HTTP proxy) has landed. ({{bug|378637}}). Enables us to work securely with web accelerating proxies.
* Akamai will be demo-ing opportunistic encryption (i.e. TLS w/o certs) with us at the upcoming IETF meeting in New York.

===Performance (vladan)===



No update this week

===Seceng (mmc)===


* Ability to test testing public key pins landed last night. We want testers to set "security.cert_pinning.enforcement_level" to 3 and see what breaks, telemetry says errors are less than 10^-4 so we are feeling good about going to production soon.
* {{bug|973837}} has landed and been uplifted to Beta. It blocks view-source URI's in the data attribute on <object>, which prevents a variant of the same security hole that necessitated blocking the URI on iframes a few months ago.

===Shumway (tschneidereit)===



===WebAPI (overholt)===


* No update this week.

==Roundtable==
(Comments and questions that arise during the course of the meeting or otherwise do not have a section.)
<Read only>
 
* (:bajaj) Firefox OS 2.0 Sprint #1 Review Report can be found [https://docs.google.com/a/mozilla.com/presentation/d/1KeJpUxavF7jN89iyvPtA9NAE4wshGF5i7XYE3OYn2o0/edit#slide=id.g3866cb49f_425 here] (You will need a mozilla google doc/drive account to view it!)

==<Read only beyond this point>==

===Friends of the Tree===
There were great changes by volunteers in Core and Toolkit during the past week. Thanks to all of these contributors for their passion and hard work, and say hi to new contributor '''Yash'''! Here are some highlights:

* '''Tom Schuster (evilpie)''' updated the Qt port ({{bug|1008668}}).
* '''Robert Utasi (hunboy)''' corrected some about:networking UI ({{bug|1011425}}).
* [first patch!] '''Svetozar Janjic''' improved MIPS support for SpiderMonkey ({{bug|996561}}).
* '''Rafael Vieira''' performed RefPtr/nsRefPtr maintenance ({{bug|1009228}}).
* '''Fred Wang (fredw)''' improved MathML styling ({{bug|930504}}).
* '''Brian Smith (bsmith)''' improved libpkix ({{bug|1006041}}, {{bug|1006958}}, {{bug|1010581}}, {{bug|989564}})
* '''Masatoshi Kimura (emk)''' fixed the download manager not respecting security settings ({{bug|1008778}}, {{bug|1008851}})
* [first patch!] '''Kestrel''' fixed dragging text selections within links ({{bug|998278}}).
* '''Arpad Borsos (Swatinem)''' fixed a SpiderMonkey spec compliance problem ({{bug|1007285}}, {{bug|474369}})
* '''Julien Levesy''' added a new IonMonkey instruction ({{bug|1008707}}).
* '''Anuj Agarwal (anujagarwal464)''' modernized some hashtables ({{bug|984123}}).
* '''Adam (hobophobe)''' fixed an intermittent orange ({{bug|1008450}}).
* '''Martin Stránský''' fixed a GTK3 crash ({{bug|909082}}).
* [first patch!] '''Inanc Seylan''' added several IonMonkey instructions ({{bug|1003802}}, {{bug|1009967}}, {{bug|1010339}}).
* '''Xidorn Quan''' fixed a vertical positioning layout issue ({{bug|1011461}}).
* [first patch!] '''qeole''' made the plugin timeout value configurable ({{bug|1007490}}).
* '''Alex Vincent (WeirdAl)''' provided addons with a standard directory for data ({{bug|915838}}).
* '''Arnaud Bienner''' improved HTML button display ({{bug|1007278}}).
* '''Girish Sharma (Optimizer)''' added an API for determining if a module has been loaded ({{bug|1004487}}).
* [first patch!] '''Althaf Hameez (ahameez)''' improved OOM message recognition ({{bug|1001206}}).

===Mailing List Threads===
(Threads that are likely to be of interest to engineering from various mailing lists.)

===Good Reads===
(Links to blog posts, books, videos, etc. that you think will be of interest to others.)

===irc #planning Log From This Meeting===
<pre style="white-space:pre-wrap;">
10:46 KaiRo: cpeterson: no voice update from stabiliy, and I will miss the meeting due to a conflict
10:46 cpeterson: ok
11:01 blassey: cpeterson: drop the notes link?
11:01 cpeterson: blassey: https://wiki.mozilla.org/Platform/2014-05-20
11:02 davidb: toronto on the way
11:08 blassey: milan_: why do we need to support 1.3 on the flame?
11:08 milan_: blassey: because of "sora" device which is close to flame
11:08 milan_: blassey: and nobody has sora...
11:08 overholt: we could have Hudson/Jenkins-style weather reports next to team reports
11:08 bmoss: milan_: is there anything we can do to help you?
11:08 milan_: blassey: and you can't build 1.3 for Flame without some hoop jumping :)
11:11 blassey: I haven't heard of the sora device
11:14 davidb: grobinson, TIL bug 973837 was fixed. thanks for that :)
11:14 grobinson: davidb: yeah, np, that was all bobowen
</pre>

Firefox OS/Performance/Triage

2014-05-14T18:06:28Z

Mlee: /* Blockers */

=Schedule=

* Triage: Wednesdays from 11am - 12pm PT
* Vidyo: [https://v.mozilla.com/flex.html?roomdirect.html&key=wesmNpztjIXi FxOS_Performance]
* IRC: irc://irc.mozilla.org:6697/#fxos-perf

=Queries=

==Blockers==
* Conventions
** ...'''?''' = blocker nominations = bugs nominated as something that should block that release.
** ...'''+''' = blockers = bugs accepted as being a release blocker.
** Blocking criteria can be found at: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines

* Queries
** [[CrashKill#Firefox_OS|Crashes]]

** [http://mzl.la/IP2FbM 1.3+]
** [http://mzl.la/1ieaOSq 1.3T+]
** [http://mzl.la/1hgZzua 1.4?]
** [http://mzl.la/ODfM2U 1.4+]
** [http://mzl.la/1eFcbr7 2.0?]
** [http://mzl.la/1hO0yhF 2.0+]

==Candidates==

* [http://mzl.la/1fI58AW Untagged]
** Add '''perf''' keyword and Scrumbugs tags for all FxOS Performance issues.
** Add '''perf-reviewed''' whiteboard for bugs that are not FxOS Performance issues.
** Sort by ascending bug ID

==Unprioritized Backlog==

* [http://mzl.la/1mJ78yU All Open]
** Set Priority for all bugs covered in each triage session.
** Match [MemShrink:P?] priority when set unless bug is a release blocker.
** Close bugs that no longer reproduce or that no longer match product requirements.
** Identify blockers and relevancy.

=Keywords=

; footprint: Add to bugs regarding memory footprint performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; mlk: Add to bugs regarding Out Of Memory (OOM) performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; perf: Add to bugs covering regarding all types of performance or performance impact in FxOS, for tracking by the FxOS Performance team. Scrumbugs tags should also be added, see below.
; regression: Add to bugs where a regression has occurred; previously working functionality has been broken or performance goal is no longer being met.
; regressionwindow-wanted: Add to bugs where the commit that caused the regression needs to be identified.
; qawanted: Add to bugs where performance needs to be verified (or re-verified) by QA. Specific instructions should always accompany this keyword.
This list is not comprehensive, and only includes keywords used very frequently by the FxOS Performance team during triage. For the full list of keywords and their descriptions see: https://bugzilla.mozilla.org/describekeywords.cgi

=Whiteboard Entries=

; [perf-reviewed]: Add to bugs that appear in an Untagged triage but should not be tracked by the FxOS Performance team. Excludes from future triages.
; [MemShrink]: Add to bugs that should be looked at by the [https://wiki.mozilla.org/Performance/MemShrink MemShrink team] responsible for maintaining efficient memory usage on FxOS.
This list is not comprehensive, and only includes whiteboard entries used very frequently by the FxOS Performance team during triage.

=Prioritization=

Prioritization of tasks is defined on a scale of decreasing priority from P1 to P5.

; [P1]: Any bug that is designated a blocker. Can also be used on tasks that we deem critical for our team to complete.
; [P2]: Bugs that are deemed important to solve but are not classified as blockers. Can also be used for critical engineering research tasks.
; [P3]: Lower priority bugs. Can also be used for common engineering research tasks.
; [P4]: Engineering research tasks for open schedules or down-time.
; [P5]: Dated bugs that have not been followed up on recently.

=Scrumbugs Tags=

Scrumbugs tags are added to the Whiteboard field in Bugzilla, but are actually directives to [http://scrumbu.gs Scrumbugs] for how to organize the bugs within sprints and backlogs.

The tags follow the format:

''[c=<component> p=<points> s=<sprint> u=<milestone>]''

Brackets are optional, but will help keep the tags from being accidentally mixed up with other whiteboard entries and not parsed by Scrumbugs. Spacing is significant; no spaces should be on either side of the equals. Order is not significant.

Tags may appear but be left empty, e.g. ''[c= p= s= u=]''. This will be sufficient to direct Scrumbugs to track the bug. Other valid values for tags are explained below.

Not all tags must appear, but our queries expect that any bug tracked by the FxOS Performance team will have the Component tag at minimum.

More information about Scrumbugs can be found on the [http://scrumbu.gs/help/ Scrumbugs Help Page]. Examples may be found on the [http://scrumbu.gs/t/fxos-dev-mlee/ FxOS Performance team's Scrumbugs page].

==c= Component==

The FxOS Performance team is generally less concerned about what module of code a bug affects (the Bugzilla component) than what kind of performance the bug impacts. Components are typically overridden via the Component tag to refer to particular user stories representing broad performance targets.

; (no value): use the component from Bugzilla
; automation: Automation-related
; benchmark: Performance Benchmarks
; boot: Boot Sequence (boot-2-homescreen)
; devtools: Development Tools
; documentation: Documentation
; effect: Perception of cause & effect
; handeye: Hand-Eye coordination
; memory: Memory leaks or footprint.
; power: Power Management
; profiling: Profiling tools
; progress: Perception of progress
; uniformity: Frame Uniformity

More information may be found at [[../UserStories]].

==p= Points==

Point values are estimates of effort ranging from 1 to 5 set during Sprint Planning. They can be adjusted during a sprint cycle as their related issues become better understood. Point values are not usually set during triage.

{| border="1" cellpadding="5"
! Points !! Meaning
|-
! (no value)
| Unestimated
|-
! 1
| Clearly understood and trivial.
|-
! 2
| Clearly understood and non-complex.
|-
! 3
| Average, requiring investigation but not significant effort.
|-
! 4
| Difficult, requiring non-trivial investigation and implementation expected to take half or more of a sprint.
|-
! 5
| Very difficult, requiring significant investigation and implementation requiring an entire sprint.
|}

Issues requiring more time than a sprint cycle must be broken into smaller issues that can each be accomplished within a sprint.

==s= Sprint==

The Sprint tag is used to direct Scrumbugs to include the bug into a particular sprint.

The value of this tag, if set, refers to the name of a Scrumbugs sprint. FxOS Performance team sprints follow a date format ''YYYY.MM.DD'', where the date refers to the day the sprint ends in the Pacific Time timezone.

If the tag is included with an unset value, it has no effect.

This tag should not be used with a set value on open bugs, as it interferes with Scrumbugs' ability to migrate the bug from one sprint to the next when necessary. Once specified this way, the bug will always need to be manually managed within Scrumbugs, even if the tag is subsequently removed.

'''A value should only be set for this tag to insert an otherwise untracked bug into the current sprint after the bug has already been resolved'''.

==u= Milestone==

The Milestone tag is actually a repurposing of the Scrumbugs User tag. For the purposes of the FxOS Performance team, it is used to indicate the FxOS Release(s) and/or Device(s) for which the bug is targeted (e.g., ''1.2'', ''1.3'', ''tarako'', etc.)

The value, if set, will be reflected in the User column of [https://scrumbu.gs/p/fxos-perf/ Scrumbugs]. If the value is unset, the tag has no effect and the column will remain empty.

=Cc=

To Cc (Carbon Copy) the perf team in Bugzilla, use perf@fxos-perf.bugs as the address. People interested just need to watch that user in bugzilla. Don't Cc the team list.