the Chromium logo

The Chromium Projects

Optimizing Energy Consumption

Background Info

Here are two really great talks on optimizing battery life:

Mac: [Maximizing Battery Life on OS X, WWDC
2013]( is a great

Android, [project volta]( talk.
(Google-internal [project
volta]( [tech
talk](http://go/volta-tech-talk-video) and

Telemetry tests

We use Telemetry benchmarks for testing and analyzing energy usage. See code concepts for details on benchmarks, measurements, and page sets.


On desktop, the tab_switching measurement opens a group of tabs and measures
energy after they are all loaded. All except the last tab are backgrounded.
You can use the benchmark with a blank page in the foreground to understand
how background tabs behave, or with a regular page in the foreground to
focus on the foreground tab.

On android, our chromium.perf tests and most of our development is on chrome
shell, which does not support tabs. So we use the power test instead. It
will load each page in the set, with a 20 second pause, a scroll, and
another 20 second pause in between each load.

Page sets

It might be a good idea to record a custom page set if you’re working on a very specific issue, for example below-the-fold animated gif. But we generally use the below page sets for most of our testing and debugging:


- This is a set of 25 web pages designed to represent general web browsing.

- The Alexa top 10 sites.

- Mobile versions of the Alexa top 10

- For debugging background noise that occurs regardless of which page you’re

- Very complex or energy-heavy pages.


- 10 typical mobile pages.


Each platform has different techniques for measuring energy usage, and often there are multiple techniques (hardware devices, software estimation). Below are the names of the metrics, the platforms they are available on, and how they are gathered.

energy_consumption_mwh - This is the energy consumption in milliwatt hours.
In general, this is a software estimation. You can see all the methods we
have for measuring energy consumption in the
directory in telemetry, but here is a quick run-down of how the bots on the
waterfall calculate this:

    Android uses
    software estimation on L release and above.

    Except Nexus 10, which uses the built in
    fuel gauge on L release and above.

    Mac OS uses
    on 10.9 and above ([more details

    Windows and Linux use
    on intel processors with sandybridge or later.

application_energy_consumption_mwh - This is derived by measuring
energy_consumption_mwh during a quiescent period before running chrome, then
subtracting that from the energy_consumption_mwh used during the test run.
The goal is to find the amount of energy used by chrome and ignore the
steady state energy used by the OS and background processes. However, if
there is too much noise this number can be off.

idle_wakeups_total - This is the total number of idle wakeups across all
processes. It’s currently only available on Mac through powermetrics, but we
are working on Linux (bug [422170]( and Android
(bug [422967](
This number is important because it’s a proxy for energy consumption, and it
figures heavily in the [Energy Impact](
score in OS X. See the [Maximizing Battery Life on OS
X]( talk for more info
about how reducing idle wakeups improves battery life.

board_temperature - Temperature in degrees celsius. Available through MSR on
Windows/Linux (intel sandybridge and later). Also available on Android
devices running L release+.

Developing/Testing Locally

Choose or record a telemetry page set that matches the use case you want to

Run the correct telemetry benchmark for your platform (tab_switching for
desktop, acceptance test for android). Use the --profiler=trace and
--pageset-repeat=1 flags; this will output a trace and only repeat the test
once. Example:
tools/perf/run_benchmark tab_switching.five_blank_pages \\
--browser=release --profiler=trace --pageset-repeat=1

Telemetry outputs a trace file. You’ll see the file name in stdout. Open it
up in
Look for places where:

    Chrome is doing unexpected work. For example, a timer that wakes every
    1s on a blank page should not be needed. Removing unneeded timers is a
    great way to reduce idle wakups.

    Work is happening too frequently and could be coalesced. Could two IPCs
    be grouped into one? Doing the same amount of work with fewer IPCs
    reduces idle wakeups.

Comparing traces between two builds that have different energy usage can also be helpful. You can use the --browser argument in telemetry to easily run the test on your stable, beta, or dev channel and compare that with a local build (--browser=release or --browser=debug).

Verifying Results on Perf Bots

Energy measurements are very sensitive to noise. Sometimes you make a change locally that drives down idle wakeups and you believe will reduce energy consumption, but the energy numbers you get are just noise. Sometimes you don’t have access to the OS or hardware you want to test. The chromium.perf and tryserver.chromium.perf bots can help!

Perf Try Jobs

You can run tab_switching tests on the perf trybots on the tryserver.chromium.perf waterfall. Here is the documentation for perf try jobs. If idle wakeups numbers are available, they will be in the “memory” tab of the results html page.

chromium.perf waterfall

Several energy tests are running on the chromium.perf waterfall:






You can look at the effects of a submitted change. After bug 423394 is fixed, you will be able to get traces for some of the runs as well.