Performance/Project Candle

Project Candle ran from 2015-2016.

Project Candle aims to reduce the power consumption of Firefox (on desktop and mobile) and Firefox OS, in order to increase battery life for users on mobile devices. Some reductions in power consumption will also help improve performance, such as those that reduce CPU usage.

Project Candle is a Platform Engineering initiative that aims to extend and complement existing work relating to power consumption within Mozilla.

Mailing list

The mailing list still exists, but in practice nobody is posting to it for now.

The Project Candle mailing list is called dev-power.

Instead of having regular face-to-face meetings, this list will serve as the central point of contact for all discussions and bug triaging for Project Candle. While having no face-to-face meetings does reduce the immediacy of discussion, we hope this will be outweighed by other advantages.

First, given that the reduction of power consumption potentially requires people with expertise in many parts of the codebase, it is important to avoid excluding anybody. A mailing list achieves this in the following ways.

• Nobody needs to miss discussion due to being permanently in a particular timezone.
• Nobody needs to miss discussion due to being temporarily unavailable at a particular time.
• It's easy to "lurk", i.e. follow along in a low-commitment fashion.

Second, there are some practical benefits.

• All discussions are permanently archived.
• Fewer meetings for everybody.

If you are interested in helping or even just following progress, joining the mailing list is the single best thing you can do.

IRC

The #power channel is for discussions relating to power consumption.

Bug tracking

Triage threads are not being performed at the moment, and "[Power]" whiteboard annotations are currently not being used.

Bugs are prioritized via periodic triage threads on the mailing list. The process is described in the section below.

If you want a bug that is related to power usage to be triaged on the mailing list, add "[Power]" to the bug whiteboard. After prioritization, this whiteboard marking will be changed to one of "[Power:P1]", "[Power:P2]", "[Power:P3]" or "[Power:meta]". The meaning of these markings, and links to all such bugs, is as follows.

• Unprioritized Power bugs. These are prioritized regularly on the mailing list.
• Power:P1 bugs. Once prioritized, these will be revisited and discussed occasionally on the mailing list. We will try to keep the number of such bugs small and constant, e.g. a dozen or so.
• Power:P2 bugs. Once prioritized, these will be revisited and discussed rarely on the mailing list. P2 is the default priority, and should be used when a bug is not obviously important or unimportant.
• Power:P3 bugs. Once prioritized, these are unlikely to be revisited and discussed again on the mailing list.
• Power:meta bugs. Once prioritized, these will be revisited and discussed occasionally on the mailing list.

Some other interesting bug lists that overlap with the ones above.

• All Power bugs.
• Unconfirmed Power bugs. These are problems reported by users and generally require some kind of additional work to confirm.
• Power bugs with a "mentor" annotation. These are bugs that someone has identified as reasonable easy, and that person is willing to help a newcomer fix the bug.
• Unassigned Power bugs. These need someone to work on them.

There is also a "power" keyword in Bugzilla, but this won't be used by Project Candle because the whiteboard annotations described above are more flexible.

Bug triage process

The email-based triage process turned out to be flawed. The responsibility, borne by a single person, to write something substantive for every nominated bug was onerous. Synchronous meetings will likely be more effective.

These threads will have a title such as "Project Candle bug triage (7th September 2015)". The triage manager will initiate these threads, listing each bug, asking relevant questions, and suggesting priorities.

The primary purpose of these threads is to get eyes on bugs that have been marked with the "[Power]" whiteboard marking and to triage them. If we can also find people to do further investigation and/or assign themselves to a bug, even better, though that is not expected to happen with every bug.

So please take a few minutes to look through the listed bugs. For each bug, decide if you agree with the suggested priority, and consider if you can add to the discussion in the bug, suggest somebody who might be able to work on it, or even take it on yourself.

Note also that these email threads are substituting for face-to-face meetings where basic agreement can be achieved quickly and obviously. In contrast, on mailing lists it is harder to reach agreement like this, particularly because the bar for response is higher and it is traditional to avoid responding with simple "I agree" messages. Nonetheless, for these triage threads we specifically encourage this kind of response. In particular, if you agree with all the suggestions a simple "+1" response is helpful. Without such responses, it is likely that there will be few responses and the triage manager -- who took the time to write the message that starts the thread -- won't know if it's because (a) everybody agrees with their suggestions, or (b) nobody looked at the bugs, or (c) nobody cares. This lack of information is discouraging.

A few days later, after discussion has occurred, the triage manager will update the bugs appropriately.

Documentation and Tools

The "Power profiling" section of the MDN performance page has a link to a power profiling overview document that introduces many concepts relevant to power profiling. That section also has links to a number of other documents that describe tools that can be used for power profiling.

MicroSoft wrote about how they improved the power consumption of Edge.

Progress tracking

We will need to set up some kind of automated system for tracking power consumption. This will let us measure progress and also detect regressions.

There are several open questions relating to this.

• Which platforms? (Note that dedicated hardware is best for power consumption measurement, because a lot of the tools do system-wide measurements.)
• Which other browsers do we compare with?
• Which metrics do we use?
• What workloads do we test?

For Firefox, Roberto Vitillo's Energia dashboard may serve as a good starting point. (Note that this dashboard has not been updated in over a year and so its actual data should be ignored at this time.)

For Firefox OS there are already current measurements being made and fed into Raptor.