Why you should measure the energy of your software …
The holy grail : load time.
The page load time was the last time the key indicator when talking about optimizing websites. This has improved many sites or at least to structure the domain of web optimization. Good. However, we have taken a first pass and we have not reached the summit optimization.
When talking about optimization metric, we talk mainly metrics visible to the user. That is why indeed the loading time came first. This is a metric that everyone can understand. I click, the page is not, I expect, it appears! The articles in blogs, best practices… most of the industry is working on this. The GRAIL of the descent behind the second. It’s a good thing because it has optimized the size of some websites. The RAIL model is a good example of these improvement : reduce response TIME, reduce animation TIME, increase idle TIME, reduce load TIME. Great model…
However the fight is not finish. We can see it with the bloat of website with HTTP archive. More and more data :
We must continue to improve the performance of web sites and applications. Is that users see and wonder. And to continue to find optimization, we need other metrics. Why ? because a chemist does not work with only litres, but with pH, temperature …
When we begin to study the classics of software metrics such as CPU or memory, you can not find the user needs, not directly. This is normal because they are metrics “technical” not directly visible to the user. High CPU consumption will create a real slowing of the user computer, but he will not understand it.
Moreover, profiling CPU and memory is not so simple. I leave specialists (Intel) explains this :
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 ? Don’t forget CPU, just be careful about its usages. No directly related to user. Moreover, CPU is not the only part of devices. Especially on mobile platform : screen, radio cell, GPU… Profiling one metric was difficult, so profiling several will not a realistic way for developers.
Energy : Another metrics
CPU use energy, radio cell use energy, GPU, use energy… So why not to use energy ? As in a car or speed is important, resource consumption is measured fuel consumption.
The energy is a little more. If, think about your state of nervousness when you’re lost in the city with your phone without battery and you do not have the address of your next appointment, no Google Maps or GPS …
The energy measurement is common in the material world but not the software world. Well yes, it’s virtual! 5 years ago when we started talking to measure energy to developer, we heard a lot of argument against! But we done it. Smartphones now embed energy sensors, servers in data centers also … and API software can retrieve this information. The brake is more the lack of tools, knowledge in energy …
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 ;-)
How to measure ?
In Greenspector, we work on energy probe and we try to simply existing tools and API to provide it to developpers. On good exemple is the Green Code Lab Challenge where we measured energy of Raspberry and server.
Energy meters are more and more embbeded in hardware. The example is Android where you can find an API since Android 5 to get the hardware information about energy. It is simple :
BatteryManager batteryManager = (BatteryManager)context.getSystemService(Context.BATTERY_SERVICE);
mEnergyNWH = BatteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER);
The energy is constant in software ?
No. We have measure for the projet Webenergyarchive.com, the consumption of web page loading in a smartphone. A first finding is that energy is not constant.
The sites use an average of 10 mAh. Taking a battery with a capacity of 3200 mAh (like the Nexus 6), so we have a range of 320 views site before discharging the battery.
If we take the 20 lowest consumer sites, has an average of 6.8mAh against 16.0mAh 20 for more consumers. It makes a difference of 470 views for least 200 consumer sites against either a passage of 467 minutes of autonomy to 200 mn. The implementation of the sites therefore has a real impact on the battery life of phones.
We can also analyze energy websites in terms of discharge rate. On average we have a discharge rate of 202 uAh/s for the page loading and 143 uAh/s for the page idle. For information, the consumption of the phone without browser and without site is 100 uAh/s. There is thus a doubling of the load in discharge rate. Similarly, the idle site consumes significant energy (impact 43 uAh/s). This shows the importance of optimizing this state (and not only the page loading). For that, here are some ideas:
- unbinding some data from memory
- Stopping or limiting scripts during idle
- …
Here the Ah of an android application is Idle in foreground :
Versus application on background :
Energy give us here an important information about domains of optimization : It confirmed that we need to continue to optimize the page loading but we need also to work on the idle of the page.
And now ?
Measure, measure, measure … Performance culture need to be known by every developers. Inside this culture, the energy measurement have an important place. Tools are youngs, domain is new… but we need to begin. We begun and i recommended it.
The current performance models 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 an M (for memory), turning into BLAIMR, PRIMAL. Good. Like we have a performance budget, we need a energy budget. Your software should not have an impact which double the energy discharge of the battery. Your software should not have an impact which increase by more that 10% the discharge rate of the battery in Idle…
But before model, we can simply measure. And watch the curve. We will learn a lot of things.