Here are two really great talks on optimizing battery life:
Mac: Maximizing Battery Life on OS X, WWDC 2013 is a great overview.
Android, project volta talk. (Google-internal project volta tech talk and slides)
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.
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:
Desktop:
Android:
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 power_monitor directory in telemetry, but here is a quick run-down of how the bots on the waterfall calculate this:
Android uses dumpsys software estimation on L release and above.
Except Nexus 10, which uses the built in ds2784 fuel gauge on L release and above.
Mac OS uses powermetrics on 10.9 and above (more details here).
Windows and Linux use MSR 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+.
Choose or record a telemetry page set that matches the use case you want to test.
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 about:tracing. 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).
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.