💻 computer science

Watts This Smell: A Comprehensive Taxonomy of Software Energy Smells

This paper introduces a comprehensive, language-agnostic taxonomy of 12 software energy smells and 65 root causes, which is empirically validated through the analysis of over 21,000 Python code pairs to demonstrate that energy optimization is distinct from performance optimization and to provide a foundational resource for green software engineering.

Original authors: Mohammadjavad Mehditabar, Saurabhsingh Rajput, Tushar Sharma

Published 2026-07-09

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Mohammadjavad Mehditabar, Saurabhsingh Rajput, Tushar Sharma

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a chef running a massive, 24-hour restaurant. You have a menu of thousands of dishes (software programs) that you serve to millions of customers every day.

For a long time, you only cared about one thing: Speed. "How fast can I get this dish out of the kitchen?" you asked. If a dish took 10 seconds instead of 12, you were happy.

But recently, you realized something scary: Speed isn't the whole story. Sometimes, a dish that comes out faster actually uses a massive amount of electricity because the chef is frantically running back and forth, turning the oven on and off, or using a giant, inefficient blender. This is the problem this paper tackles. It's about finding the "energy smells" in your kitchen code—the bad habits that waste electricity even if the food tastes fine.

Here is a simple breakdown of what the researchers did:

1. The Big Problem: Speed vs. Energy

The paper starts by busting a common myth: "Faster always means greener."

The Analogy: Imagine driving a car. You can drive to the store in 5 minutes by speeding and slamming on the brakes (high speed, high fuel burn). Or, you can drive in 7 minutes by coasting gently (slightly slower, but much less fuel).
The Reality: In software, writing code that runs fast doesn't always save energy. Sometimes, making code faster actually makes the computer's processor work harder and draw more power, wasting energy overall.

2. The Solution: A "Smell" Taxonomy

The researchers wanted to create a dictionary for these bad habits. They called them "Energy Smells." Just like a bad smell in a house tells you something is rotting, a "code smell" tells a developer something is inefficient.

They didn't just guess; they went on a massive treasure hunt:

The Hunt: They read 60 different scientific papers and screened over 400 other documents to find every possible way code wastes energy.
The Sorting: They found 320 different bad habits. They then organized these into a neat, two-level family tree:
- Level 1 (The Category): The general type of smell (e.g., "Wasted Work" or "Bad Memory Use").
- Level 2 (The Root Cause): The specific thing you did wrong (e.g., "You calculated the same math problem twice" or "You kept a heavy object in memory when you didn't need it").

The Result: They created a map with 12 main categories and 65 specific root causes. This is the first time such a comprehensive, language-agnostic (works for Python, Java, C++, etc.) map has been made.

3. The Proof: Testing in the Real World

A list is useless if it doesn't match reality. So, the researchers built a giant test kitchen.

The Dataset: They took 21,000 pairs of code. In each pair, one version was the "bad" way and one was the "good" way, but they both did the exact same job.
The Measurement: They measured exactly how much electricity, time, and memory each version used.
The AI Detective: They used a super-smart AI (an LLM) to look at the top 3,000 worst offenders and ask: "Which of our 65 smells is causing this waste?"

What they found:

The AI was right: The AI successfully matched the bad code to their new map in 85% of the cases. This proved their map is real and useful.
Multiple Smells: Most bad code (71%) wasn't just one smell; it was a cocktail of several bad habits happening at once.
The Big Winners: The biggest energy savers weren't always the fastest code. Fixing memory issues (like holding onto data you don't need) saved the most energy.
The Surprise: Sometimes, fixing a problem made the code slower but saved more energy. This proves you can't just look at speed; you have to look at the power bill.

4. Why This Matters

Think of this paper as giving developers a universal "Check Engine" light for energy.

Before, developers might have fixed a slow program without realizing they were actually wasting electricity.
Now, they have a shared vocabulary. If a developer sees a "Redundant Computation" smell, they know exactly what to fix to save power.

The Bottom Line

The researchers didn't just find a few bad habits; they built a complete encyclopedia of energy waste in software. They proved that to save the planet (and money), we need to stop looking only at how fast software runs and start looking at how efficiently it uses power. They even released their "test kitchen" data and the map for everyone else to use, so the whole world can start cooking greener software.

Technical Summary: Watts This Smell: A Comprehensive Taxonomy of Software Energy Smells

Problem Statement

As software proliferates across domains, its aggregate energy footprint has become a critical environmental concern. While "code smells" are well-established as structural anti-patterns that degrade maintainability, a parallel class of "energy smells" exists: source code implementations, design choices, or programming practices that lead to inefficient hardware resource usage and unnecessary energy consumption.

A significant misconception in software engineering is treating execution performance and energy consumption as interchangeable metrics. While correlated, they measure distinct phenomena. Performance primarily reflects execution time ( $T$ ), whereas energy consumption ( $E$ ) is the product of power draw ( $P$ ) and time ( $E = P \times T$ ). Faster execution does not guarantee lower energy consumption; a code change that reduces time may simultaneously increase power draw, resulting in higher total energy. Furthermore, existing catalogs of anti-patterns are often domain-specific (e.g., Android-only), limited to performance metrics, lack fine-grained root cause classification, or remain unvalidated against measured energy data. There is a need for a comprehensive, language-agnostic taxonomy that bridges the gap between identifying inefficiencies and actionable refactoring.

Methodology

The authors developed a two-level taxonomy through a rigorous, multi-phase process combining systematic literature review, grounded theory coding, and empirical validation.

1. Taxonomy Construction

Literature Search: The authors conducted a systematic search in Scopus and performed exhaustive forward and backward snowballing. This process screened over 400 works, ultimately retaining 60 relevant studies (including 15 from the initial search and 45 from snowballing) that identified code-level performance or energy inefficiencies.
Data Extraction: From these studies, 431 distinct anti-patterns were initially identified.
Filtering and Coding: Two independent annotators applied inclusion/exclusion criteria to filter for language-agnostic constructs, retaining 320 relevant patterns. They then applied a grounded theory coding process (Open, Axial, and Selective coding) to:
- Open Coding: Isolate fundamental root causes by stripping application-specific context.
- Axial Coding: Merge redundant codes and split conflated mechanisms.
- Selective Coding: Abstract refined codes into high-level categories based on their overarching impact.
Finalization: Through collaborative resolution, the team finalized a taxonomy consisting of 12 primary energy smell categories and 65 root causes (subcategories).

2. Empirical Validation

To validate the taxonomy, the authors constructed a labeled dataset and applied an automated classification pipeline:

Dataset: They utilized the Python splits of the Pie-Perf dataset (derived from IBM CodeNet), filtering 36,857 instances down to 21,428 functionally equivalent code pairs with verified time and memory metrics.
Energy Profiling: They empirically measured energy consumption for these pairs using Linux perf and time tools, capturing CPU/RAM energy and peak memory usage.
Sample Selection: The top 3,000 pairs with the highest absolute energy differences were selected for deep analysis, accounting for 98.4% of the total energy variance in the dataset.
LLM Classification: A multi-step pipeline using the DeepSeek-V3.2 (685B) reasoning model classified the 3,000 pairs. The pipeline operated in three steps:
1. Root Cause Analysis: Identifying inefficiencies without prior exposure to the taxonomy labels.
2. Category Triage: Mapping causes to high-level categories.
3. Subcategory Classification: Refining into specific root causes.
Evaluation: A human-annotated ground truth was established on a random subset of 100 samples. The pipeline achieved 94% exact-match accuracy and a micro F1 score of 0.97, confirming the taxonomy's applicability to real code.

Key Contributions

Comprehensive Taxonomy: A language-agnostic, two-level taxonomy of 12 energy smell categories and 65 root causes. The categories span from low-level hardware effects (e.g., poor hardware locality) to high-level algorithmic choices (e.g., suboptimal algorithms).
Labeled Dataset: A publicly available dataset of 21,428 code pairs with verified energy, memory, and time measurements. This includes a manually validated subset of 3,000 pairs annotated with multi-label smell classifications and step-by-step reasoning traces.
Empirical Analysis: An analysis of the prevalence, co-occurrence, and energy impact of each smell category, providing evidence that energy optimization cannot be reduced to performance optimization alone.

Key Results

Prevalence: The taxonomy successfully mapped 84.6% (55 out of 65) of the root causes to the 3,000 classified code pairs. The most prevalent categories were Suboptimal Algorithmic (C7, 41.6%), Unnecessary Memory Usage (C6, 38.9%), and Inefficient Iteration Patterns (C3, 33.3%).
Co-occurrence: 71% of the samples exhibited multiple co-occurring smells. Multi-label cases showed significantly higher energy waste (median savings of 1,659 J) compared to single-label cases (549 J), indicating that inefficiencies compound.
Impact vs. Frequency: There is a misalignment between the frequency of a smell and its energy impact. While Suboptimal Algorithms (C7) were most common, Memory-related smells (C5 and C6) yielded the highest median energy savings per fix (3,989 J and 3,670 J, respectively). This is because memory inefficiencies increase both execution time and power draw, whereas algorithmic inefficiencies primarily affect time.
Power Variance: Power draw varied significantly across patterns (60.5 W to 147.3 W). In 69.1% of samples, the energy ratio exceeded the time ratio, proving that naive estimation ( $E = \text{constant} \times T$ ) systematically underestimates energy waste.
Design vs. Implementation: Design-level smells (e.g., data structure choice) produced higher median energy savings (1,537 J) than implementation-level smells (1,146 J), supporting the notion that deeper architectural fixes yield larger gains.

Significance and Claims

The paper posits that a well-defined taxonomy of energy smells provides a shared vocabulary and actionable refactoring guidelines for the software engineering community. By distinguishing energy efficiency from mere performance optimization, the work enables:

Green Software Engineering: Developers can refactor code to improve energy efficiency alongside maintainability and performance.
Tooling Development: The taxonomy serves as a foundation for static analysis tools, IDE linters, and CI/CD safeguards to detect and prevent energy waste.
AI-Driven Optimization: The labeled dataset and reasoning traces can train generative AI models to synthesize energy-efficient code and perform automated refactoring.

The authors emphasize that their taxonomy is not a replacement for performance anti-patterns but a necessary expansion, as optimizing for speed alone does not guarantee energy efficiency. The work aims to operationalize energy awareness in standard software development workflows, moving from measuring waste to actively eliminating it.