"When you can measure what you are speaking about, and express it in numbers, you know something about it." - Lord Kelvin, 1883
Try weighing a single grain of rice on your kitchen scale. It will say zero, every time. Not because the grain weighs nothing but because the scale is not built to notice something that small.
That is roughly the problem we hit while trying to measure how much energy a tiny piece of code, like a single for loop or one if statement, actually consumes.
The problem: our instruments are too slow for our code
The standard way to measure software energy today is to run the whole program and read a chip-level counter called RAPL (Intel's Running Average Power Limit). It is a solid tool, but it only updates about once every millisecond. Most individual code blocks finish executing in a few microseconds, which is a thousand times faster than RAPL can even register. Point it at one of these tiny blocks and you will often get back a zero, or wildly different numbers each time. The result: developers only find out about energy problems after the whole program has run, when it is expensive to fix. It is a bit like only being shown your total grocery bill at checkout, with no idea which item drove up the cost.
We wanted developers to see the energy cost of a loop the moment they write it, the way a spell-checker flags a typo the moment you type it, not after you have mailed the letter. That effort became two things: PowerLens, a way to reliably measure these tiny blocks, and EnCoDe, a system that learns from those measurements to predict a block's energy cost from the code alone, without running it at all.
PowerLens: turning up the volume on a whisper
If a signal is too quiet to hear, you repeat it until it is loud enough. PowerLens wraps a code block in a tight loop, runs it a thousand times, reads the total energy for the whole burst, and divides by a thousand.
Three things could wreck this trick, so PowerLens guards against each:
- Background noise. A stray process or a CPU speed change mid-measurement throws numbers off. PowerLens locks the machine down first: fixed CPU frequency scaling governor, no Turbo Boost, one dedicated core.
- Bad timing. If the burst starts mid-way through RAPL's own internal "tick," the reading gets contaminated by unrelated energy. PowerLens waits and starts exactly in sync with RAPL's clock.
- Leftover overhead. The burst may finish with some leftover time before the measurement window ends. PowerLens calibrates this "padding" ahead of time and subtracts it out.
Do all three, ten times over, discard the outliers, and you get a trustworthy reading even for code that runs in millionths of a second. To sanity-check this, we summed up PowerLens's block-by-block readings for dozens of programs and compared the total against a plain whole-program RAPL measurement of the same code. They matched closely, across every kind of construct we tested.
From measuring to predicting
Measuring still requires running the code. Developers need to know the cost while they are still writing it. So we used PowerLens to build a ground-truth dataset: over 18,000 real Python programs, broken into 8,000+ measurable blocks, each paired with its real energy cost and a "fingerprint" of 33 structural features like nesting depth, operator density, whether it has loops or conditionals, and so on.
It is the same idea as a doctor estimating someone's health from vitals rather than running every test, except here the "vitals" are code features, and the "diagnosis" is energy in joules. We trained deliberately simple, efficient models (gradient boosting, random forests) rather than heavy deep learning, since it would be a little ironic for an energy-saving tool to itself burn a lot of energy. Once trained, the model can look at a brand-new block it has never seen and estimate its energy cost purely from structure, hence no execution, no hardware, no waiting.
We expected one or two features, "number of loops" or "complexity," to dominate. That is not what we found. No single feature explains energy on its own; it is a combination of operator density, nesting, branching, and how it is all put together, and most of these relationships are curved rather than straight lines. A loop's cost depends on what is inside it, not just the fact that it is a loop. We also caught a trap: some features (like how many functions are defined) look highly predictive on the surface, but mostly act as a "type label" for the block rather than actually driving energy up or down. They describe a block without explaining its cost.
Does it actually work?
Our regression models explain about 75% of the variation in energy across unseen code (R² = 0.75), and a simplified Low/Medium/High classifier gets it right about 81% of the time. That is not a replacement for precise measurement when precision matters, but for flagging a likely energy hotspot the moment you write it, like a linter flags a code smell, it is genuinely useful.
From the lab into your editor: WattWise
To make this usable day-to-day rather than just a research result, we built WattWise, a VS Code extension that brings EnCoDe's predictions directly into the editor. As you write Python, WattWise highlights the blocks likely to be energy-hungry, right next to your code, with no separate profiling run, no hardware counters, and no context-switching out of your workflow. It is the closest thing we have right now to a live energy linter.
Most developers have no easy way to reason about the energy cost of their code today. You either need lab hardware, or you wait until deployment and profile the whole program after the fact, without knowing which part is actually responsible. EnCoDe flips that around: block-level, lint-like feedback at design time, from source code alone.
What's next
EnCoDe is currently built and validated on Python. The natural next step is extending it to other languages and testing whether the same ideas hold across different programming styles. We are also excited about applying the same block-level thinking to understanding the energy footprint of large AI models themselves, a question that is only getting more urgent.
If you want the details, the paper and code are linked below.
Paper: EnCoDe: Energy Estimation of Source Code At Design-Time, EASE 2026. Arxiv
Code & artifacts: Code
This work was carried out by the SA4S Research Group in the Software Engineering Research Center, IIIT Hyderabad, and presented at EASE 2026 in Glasgow.