Why you should measure the energy consumption of your software

Posted on by Olivier PHILIPPOT
Reading Time: 7 minutes

The page load time has for long been the key (and sole) indicator for optimizing websites. This has helped to improve many sites, or at least to structure the domain of web optimization by being a universally shared metric. Fine. But have we gone as far as we could get? Couldn’t other metrics help us go further?

When talking about optimization metrics, we often consider the metrics that are directly perceptible by the user. This is why the loading time came first. This is a metric that anyone can understand. I click, I wait for some time, then the page appears! The shorter this waiting time, the better. Indeed, most of the software industry is working from this point of view and you may read lots of blog posts, documents and pieces on this matter. The “Grail” of this quest is to get below one second of waiting time. All right, following this rule of thumb has been a good thing because it has helped to optimize the size of many websites. The RAIL model is a good example of these improvements: reduce response TIME, reduce animation TIME, increase idle TIME, reduce load TIME. Great model…

However the fight is not over. You may check the evolution of websites throughout time on HTTP archive. The average web page is still getting heavier and heavier:

Hence, we must continue to improve the performance of web sites and applications. And to explore new optimization areas, maybe we need to use other metrics. We are currently like a chemist trying to analyse a liquid by measuring its volume in litres, ignorant of other dimensions that could help him/her improve his/her knowledge: pH, temperature, viscosity… When developers began studying the basics of software metrics such as CPU or memory, they couldn’t assess these against user needs, because user needs are expressed in common language, not in CPU load. These metrics are “technical” and not directly visible by the user. A high CPU consumption will lead to a real slowdown of the user’s computer, but they will not understand a CPU value shown to them. This is where “page load time” came in handy. Moreover, even for specialists like Intel’s, profiling CPU and memory load is not trivia, as Intel wrote

“The current implementation of this metric (the number that the UNIX “top” utility and the Windows task manager report) shows the portion of time slots that the CPU scheduler in the OS could assign to execution of running programs or the OS itself; the rest of the time is idle. For compute-bound workloads, the CPU utilization metric calculated this way predicted the remaining CPU capacity very well for architectures of 80ies that had much more uniform and predictable performance compared to modern systems.”

So what do we do now? Don’t forget to look at the CPU load, but pay attention to its uses. It is not directly related to the user’s perception. Moreover, CPU is not the only sensitive piece of hardware in modern devices. The screen, the radio cells, the GPU (Graphical Processing Unit) and so on, also have behaviour of their own and can influence the result. Profiling one technical metric was difficult, therefore profiling several technical metrics does not look as a realistic way to go for developers.

One (other) metric to rule them all?…

Wait a minute. In the devices, the CPU uses energy, the radio cell uses energy, so does the GPU … So why not try to use energy consumption as a unifying metric? Think about your car: speed is important, but resources consumption also, and you watch it carefully, measuring it in litres per hour (or miles per gallon if you’re on the wrong side of the pond). If you don’t watch it, you might end up with an empty fuel tank stuck in the middle of nowhere. Well, back to our devices. Imagine your feelings when you’re lost in a foreign city with your beloved smartphone bricked by an empty battery, without the address of your next appointment, no access to Google Maps or a GPS…

The energy measurement is common in the “real” world but not in the software world. Well yes, it’s a virtual world, who cares about energy? 5 years ago when we started talking to software developers about energy measurement, we heard a lot of opposing arguments. But IT has evolved fast. Smartphones now embed energy sensors, recent servers in datacenters do also, and these are ready for the devs to use. Through APIs, any software can retrieve this information. So why is it not more widely used?

Energy : Some reminders

First there is the power :
The watt (symbol: W) is a derived unit of power in the International System of Units (SI), named after the Scottish engineer James Watt (1736–1819). The unit is defined as joule per second[1] and can be used to express the rate of energy conversion or transfer with respect to time. (Wikipedia)

Power is a work per unit time. Power is ofter confused with the energy : Watt-hours. For example, a light bulb with a power rating of 20 W will consume 20Wh in 1 hour… or 40Wh in 2 hour. Not to misuse with Watt per hour, used for example to rate a ramp up of a power plant.
Energy in Wh is most important for the software because power with constantly change and the integration of the power in energy will be the good metric.
We will also talk of Ampere-hours (especially for the smartphone measure where battery are sized with Ah). But Ah is not a unit of energy.
Now you are ready to understant the following 😉

About Energy: what’s watt?

Before going further, let’s remind us of the difference between power and energy.

First there is the Power. The watt (symbol: W) is a derived unit of power in the International System of Units (SI), named after the Scottish engineer James Watt (1736–1819). The unit is defined as joule per second[1] and can be used to express the rate of energy conversion or transfer with respect to time.

So power is a unit of work per unit of time. Power is often confused with energy, which is expressed inWatt.hour (Wh). For example, a light bulb with a power rating of 20 W will consume 20 Wh in 1 hour, and 40 Wh in 2 hours. Wh shall not be confused with Watt per hour (W/h), used for example to rate the ramp up of a power plant.

Energy is of the utmost importance for software behaviour assessment, because power is a constantly changing metric, whereas its integration along time, resulting in “energy consumed” clearly shows the consumption caused by the process throughout its functioning.

Finally, on mobile devices, you may also hear people talking of “power” or “energy” consumption expressed in Ampere.hours. This is very practical because the capacity of the battery is expressed in Ah. Hence if you know how many Ah your software has consumed, you can translate it into % of battery lost. And yes, we often do this, and for easiness of expression we often refer to this consumption as energy consumption. And it’s all right to do it, as long as you know what you’re doing and you don’t forget that Ah is not a unit for power or energy, it’s a unit for electric charge.
Now that we’re talking the same language, let’s go on.

How can a developer measure the energy consumption of their software?

Nowadays, energy meters are increasingly embedded in hardware platforms. For Android, you may use an API (starting from Android 5) to get the hardware information about energy consumption. It’s pretty simple:

BatteryManager batteryManager =
(BatteryManager)context.getSystemService(Context.BATTERY_SERVICE);

mEnergyNWH = BatteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER);

Some companies, like we do at GREENSPECTOR, may provide energy probes or simplified existing tools or APIs to developers who use their solutions.

Do all software consume the same quantity of energy ?

Short answer is “No”. For the project WebEnergyArchive.com, we measured the consumption of web pages loading on a smartphone. The first finding is that energy consumption is very variable. In average, the web sites consume around 10 mAh. Given a typical battery capacity of 3,200 mAh (like the Nexus 6), this means that you can load 320 sites before completely discharging the battery. But if you do the same calculations for the 20 lowest consuming sites (with an average of 6.8 mAh) or with the 20 most consuming sites (16.0mAh), the result is 470 views at best against 200 views only for the worst. Put it the other way round: the resulting battery life for the same number of views may go down from 467 minutes to 200 minutes, depending upon the implementation of the web sites. The way in which you code your web sites has a significant impact on the battery life on the users’ smartphones.

We can also check the websites in terms of discharge rate: how much of the battery is consumed per second? On average, the discharge rate is 202 µAh/s for the page load, and 143 µAh/s for the idle time that follows (this is part of our standard scenario. You’d be surprised of how much the idle time can tell about your application’s quality). We had also measured the discharge rate of the device without any browser opened, and it was a mere 100 µAh/s. There we are: loading a web site doubles the discharge rate on the device. The same average site, simply sitting idle, also consumes significant energy (143 – 100 = 43 µAh/s). This shows the importance of optimizing this idle state, and not only the page loading. For that, you might unbind some data from memory, limit scripts during idle (or stop them altogether), and so on…
Here’s an illustration of an Android application, idle in foreground, causing a significant discharge rate :

Versus the same application in background :

Measuring the energy consumption gave us key information about optimization areas. It confirmed that we needed to continue optimizing the page loading, but that we also needed to work on the idle state of the page.

What’s next ?

Measure, measure, measure … Performance culture should be known by every developer. As a part of this culture, the energy measurement has an important role to play. The domain is new, the tools are young, but you need to start somewhere. At GREENSPECTOR we’ve started doing it for good and I highly recommend it. The current performance models also need to be improved. For example, there is this reflexion on the RAIL model proposed by Paul Irish and Paul Lewis: Add B (for battery) and M (for memory), turning into BLAIMR, PRIMAL… This sounds good. Just as you manage a “performance budget”, you can manage an “energy budget”. For example, you may settle budgets like:

  • your software shall not doubles the battery discharge rate of the device,
  • your software shall not increase the discharge rate by more than 10% when idle…

Just set your own budgets, be progressive about them, learn and improve. This takes time. And for a start, you can simply measure. And watch the curve. You will learn a lot of things about your own software.