# On the Effect of Feature Reduction on Energy Consumption: An Exploratory Study

Xhevahire Tërnava, Romain Lefeuvre, Quentin Perez, Djamel Eddine

Khelladi, Mathieu Acher, Benoît Combemale

► To cite this version:

Xhevahire Tërnava, Romain Lefeuvre, Quentin Perez, Djamel Eddine Khelladi, Mathieu Acher, et al. On the Effect of Feature Reduction on Energy Consumption: An Exploratory Study. SPLC 2025 - 29th ACM International Systems and Software Product Line Conference, Sep 2025, A Coruña, Spain. pp.1-11, 10.1145/3744915.3748463. hal-05166140

HAL Id: hal-05166140

https://hal.science/hal-05166140v1

Submitted on 22 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# On the Effect of Feature Reduction on Energy Consumption: An Exploratory Study

Xhevahire Tërnava

LTCI, Télécom Paris, Institut
Polytechnique de Paris
Palaiseau, France

xhevahire.ternava@telecom-paris.fr

Romain Lefeuvre

Univ Rennes, Inria, IRISA

UMR 6074, F-35000 Rennes, France
romain.lefeuvre@irisa.fr

Quentin Perez

INSA Rennes, Univ Rennes, Inria,
IRISA

UMR 6074, F-35000 Rennes, France
quentin.perez@irisa.fr

Djamel Eddine Khelladi

CNRS, Univ Rennes, Inria, IRISA

UMR 6074, F-35000 Rennes, France
djamel-eddine.khelladi@irisa.fr

Mathieu Acher

Univ Rennes, IUF, CNRS, Inria, IRISA
UMR 6074, F-35000 Rennes, France

mathieu.acher@irisa.fr

Benoit Combemale

Univ Rennes, Inria, IRISA

UMR 6074, F-35000 Rennes, France
benoit.combemale@irisa.fr

## Abstract

Energy consumption is a growing concern for sustainable software. Although increasingly studied, it remains largely unexplored in configurable systems growing in complexity with features. Feature reduction can eliminate software bloat, but to our knowledge, its impact on energy use has not been investigated. To fill this gap, we investigated how both *on-demand* and *built-in* feature reduction (defined later) affect the energy consumption of configurable systems. We conducted a first exploratory study using 28 programs from three systems with built-in feature reduction, namely ToyBox, BusyBox, and GNU, as well as 6 GNU programs debloated on-demand using the Chisel, Debop, and Cov tools. In our results, built-in feature reduction led to statistically significant energy decreases in 7% of the cases, while on-demand reduction, despite achieving energy decreases in 67% of cases, showed no statistical significance. However, when energy consumption increased, it was often more substantial than the reductions observed (occurring in 25% of built-in cases and 11% of on-demand cases) showing the complex and sometimes counterintuitive interplay between feature reduction and energy. Additionally, the observed strong correlation between energy consumption and execution time motivates a shift from traditional debloating goals, centered on binary size/attack surface, to energy-aware strategies that prioritize performance concerns. Finally, we provide an in-depth analysis and discuss the perspective.

## CCS Concepts

* Software and its engineering; * General and reference → Empirical studies; Performance;

## Keywords

energy consumption, configurable systems, feature reduction

## 1 Introduction

Energy consumption is nowadays a growing concern in the pursuit of a more sustainable software industry [5, 14, 16, 20, 28, 45, 47, 53].

A report from the ShiftProject [15] and others has raised environmental concerns regarding Information and Communication Technology (ICT) and called for reducing energy consumption. During the past decade, this issue has been increasingly investigated by the software engineering community (e.g., [10, 22, 36, 37, 39, 40, 43, 47]).

As software becomes more essential to our daily lives, reducing its energy consumption has become essential for sustainable software development. This paper focuses on configurable systems that allow developers to customize variants and use a subset of implemented features by activating or deactivating configuration options. However, as more features are added over time, configurable systems can become increasingly complex. For example, Linux kernel has around 15 thousand options in version 5.8 [1, 30].

One way to manage the increasing complexity of a configurable system is through feature reduction, which has been studied for several purposes, such as for defect and bug prediction [29, 49, 50]. Several studies have explored the topic of energy consumption for configurable systems, including the impact of feature interactions on energy consumption [19], the use of static analysis to evaluate energy consumption in configurable systems [11, 12], and the correlation between execution time and energy consumption [55]. However, to our knowledge, no work has studied the impact of feature reduction of configurable systems on energy consumption.

This paper addresses this gap by investigating how feature reduction can impact the energy footprint of configurable systems. We distinguish two types of feature reduction in configurable systems, as shown in Figure 1. First, *built-in feature reduction*, where developers create and use alternative systems with fewer features. These systems are made to be simpler or smaller. For example, ToyBox and BusyBox are re-implementations of GNU software with a reduced set of features (shown on the left side of Figure 1). Second, *on-demand feature reduction* is when developers debloat software to remove unnecessary features. Several research tool prototypes, such as Chisel [21], Debop [56], and Cov [57] can assist in this process. For example, GNU programs can hopefully be debloated by such tools to reduce their features (see the right part of Figure 1).

Whether developers deal with built-in or on-demand feature reduction, they end up using configurable software with reduced binary sizes and fewer features. The goal of this paper is to investigate and reveal the effect of both types of feature reduction on energy consumption in configurable software. We hypothesize that

<figure><img src="image_2.png" /></figure>

This work is licensed under a Creative Commons Attribution 4.0 International License.
feature reduction impacts energy consumption ($H_1$), as the reduction of features affects the code that is executed and can impact energy use. To explore this, we conducted an exploratory study to examine how both built-in and on-demand feature reduction impact energy consumption. For built-in feature reduction, we first selected three configurable systems, namely GNU [18], ToyBox [31] and BusyBox [54], along with 28 programs, each included in all three systems. For example, the program mkdir is available in GNU, ToyBox, and BusyBox, with different implementations and a reduced set of features in the last two systems. For on-demand feature reduction, we selected 6 GNU programs from Xin et al. [57] that have been debloated with three debloating tools, namely Chisel [21], Debop [56], and Cov [57]. For example, the program mkdir has been debloated by the three aforementioned tools, resulting in three variants of mkdir with a reduced set of features. Finally, we measured energy consumption and analyzed its correlation with the configuration options, binary size, and execution time of the programs. Programs were selected based on our ability to successfully compile and execute all three debloated variants, ensuring valid outputs for the common set of features used during debloating. The findings suggest that built-in feature reduction led to statistically significant energy decreases in ≈ 7% of the cases, while on-demand reduction achieved energy decreases in ≈ 67% of the cases, but without statistical significance. However, both approaches showed significant energy increases in some cases: 25% for built-in and ≈ 11% for on-demand. These results highlight the complex relationship between feature reduction and energy consumption. Additionally, we found a weak correlation between binary size, configuration options, and energy consumption, suggesting that smaller binaries and fewer options do not necessarily result in lower energy consumption. However, execution time showed a strong correlation, making it a good proxy for energy consumption. These findings are consistent with prior observations at the scale of entire configuration spaces [55]. The contributions of the paper are as follows.

* We distinguish two types of feature reduction and propose a terminology for them: *built-in feature reduction* for alternative program implementations with fewer features, and *on-demand feature reduction* for debloated programs.

* A novel study exploring the impact of both built-in and on-demand feature reduction on energy consumption in configurable software systems, which resulted to be nuanced with potential reductions (≈ 64%) but also notable increases (≈ 36%) in some cases. The amount of energy consumed depends on the approach used and the program.

* We identify key factors influencing energy consumption, showing that execution time is a stronger predictor than binary size or the number of configuration options, providing valuable insights for future debloating strategies.

* In addition, a replication package is made available [52].

The paper is structured as follows. Section 2 provides background on feature reduction and energy consumption. Section 3 describes our experimental approach. Sections 4 and 5 present the methodology and results for built-in feature reduction, while Sections 6 and 7 cover on-demand reduction. Section 8 offers an in-depth analysis, Section 9 discusses threats to validity, Section 10 reviews related work, and Section 11 concludes the paper with future directions.

<figure><img src="image_3.png" /><figcaption>**Figure 1: Built-in vs. On-demand feature reduction**</figcaption></figure>

# 2 Background

This section presents background on feature reduction and energy consumption methods for configurable systems.

## 2.1 Feature Reduction

Configurable software systems offer several features that activate specific functionalities or impact non-functional properties (e.g., execution time, accuracy, etc.). The goal of feature reduction is to prioritize core features that provide the most value to users while eliminating code that does not significantly contribute to the overall software system or its qualities. For example, feature reduction can simplify the system and ensure it adheres to a given usage by removing unnecessary source code, as discussed by Holzmann [23].

We distinguish two approaches to achieving feature reduction:

* *Built-in feature reduction*, where developers create alternative systems or implementations with fewer features. For example, ToyBox and BusyBox are re-implementations of GNU with reduced feature sets (see Figure 1, left).

* *On-demand feature reduction*, where configurable systems are debloated using tools such as Chisel [21], Debop [56], and Cov [57], producing variants with fewer features based on usage profiles (see Figure 1, right).

For instance, the mkdir program is on the GNU configurable system, which has a binary size of 420.60 KiB and 7 runtime configuration options. A built-in feature reduction of mkdir exists in both ToyBox and BusyBox as alternative implementations. The two alternative implementations have binary sizes of 18.60 KiB and 18.70 KiB, respectively, along with 3 and 2 configuration options. Moreover, with debloating tools, one may debloat mkdir in GNU. For example, two different debloated variants of mkdir can be produced using Chisel [21], based on usage profiles describing the use of 2 and 3 configuration options, respectively. Its debloated programs (used in this study) have binary sizes of 22.90 KiB and 16.50 KiB.

Whether built-in or on-demand, the goal of developers and users is to reduce binary size, configuration options, and attack surface of programs [21]. However, it is unclear how feature reduction impacts energy consumption and whether it correlates with other non-functional properties (e.g., binary size). In this paper, we explore the impact of both types of feature reduction on energy consumption.
## 2.2 Energy Consumption Methods

The methods for measuring energy consumption in IT have evolved over time, shifting from hardware to software. In fact, monitoring software energy consumption through hardware introduces certain challenges, including the requirement of physical instrumentation and the high level of granularity (i.e., measure at the level of the entire hardware system). This section provides an overview of software energy measurement.

Since 2011, Intel has implemented the Running Average Power Limit (RAPL) in their Central Processing Units (CPUs) to provide a more reliable measurement interface than hardware power meters [13]. RAPL reports energy consumption in joules (J), typically micro-joules (µJ), for different CPU elements like cores, integrated GPU, socket, and RAM. Intel CPUs have a Model-Specific Register (MSR) that updates at a high frequency (1 000 Hz) where the RAPL value is stored [25]. In this way, RAPL value is accessible through the operating system (OS) using the MSR, making the measurement easier and more reliable since it is directly linked to the CPU.

Several tools and prototypes are available<fnref n="1" /> to capture the RAPL value to measure application energy consumption, such as Intel Power Gadget, Intel PowerLog, Perf, PowerTOP, PowerStat, Likwid, and *Jouleit*<fnref n="2" />. They mostly rely on power monitors or energy profilers. However, Intel Power Gadget, PowerTOP, PowerStat, and Likwid are not suitable for our needs, as they cannot measure process consumption during execution. Although Intel PowerLog supports this functionality, it is only compatible with Windows. Perf, on the other hand, does not report RAPL values in a usable format like CSV or JSON. Among the available tools, *Jouleit* is the most suitable option in our context. It has the ability to monitor a process, automatically execute and monitor it multiple times, and generate reports in CSV format. Furthermore, *Jouleit* is compatible with Linux, making it the ideal choice for our needs.

# 3 Experimental Approach

In this section, we outline the research questions and the experimental approach of our study.

## 3.1 Research Questions

To answer the objective of feature reduction's impact on energy consumption, we pose the following research questions.

*Built-in feature reduction impact.* We pose the following three research questions to examine how built-in feature reduction affects energy consumption in alternative software implementations.

*RQ1.1:* How does the binary size of programs with built-in feature reduction impact energy consumption, and what is the correlation between the two?

*RQ1.2:* How does the number of configuration options of programs with built-in feature reduction impact energy consumption, and what is the correlation?

*RQ1.3:* How does the execution time of programs with built-in feature reduction impact energy consumption, and what is the correlation?

*On-demand feature reduction impact.* Next, we explore how program debloating (i.e., on-demand reduction) impacts energy consumption and whether findings on alternative implementations extend to debloated programs. From this, we pose two research questions.

*RQ2.1:* How does the binary size of programs with on-demand feature reduction impact energy consumption, and what is the correlation?

*RQ2.2:* How does the execution time of programs with on-demand feature reduction impact energy consumption, and what is the correlation?

We could not investigate the correlation with configuration options, as this information was unavailable for the debloated programs. Although, in theory, a debloated program should only handle the desired feature, there is no guarantee that the entire input space for a feature is covered.

## 3.2 Dependent and Independent Variables

Our experiment focuses on quantifying the impact of feature reduction on energy consumption in configurable software systems. In this context, the independent variable under our control is the *feature reduction* itself, specifically the *executable binary size* and the *number of run-time configuration options* in software programs, both before and after feature reduction. To address our research questions, we observe and measure two dependent variables, namely the *execution time* and *energy consumption* of software programs.

## 3.3 Measurement Setup

We measured software power consumption using the RAPL [27] value, which specifically relates to the Package-Level Power (PSYS), representing the entire CPU, including cores, cache memory controller, and iGPU. The RAPL values are captured using a tool from the PowerAPI<fnref n="3" /> toolkit [7] called *Jouleit*<fnref n="4" />. All energy consumption measurements are expressed in micro-joules (µJ).

However, there is still the issue of effectively communicating the meaning of the measured energy consumption. While RAPL values are provided in micro-joules through the CPU interface, this unit may not be easily understandable for developers and end-users. To make energy consumption values more meaningful, we propose converting them into the usage time of common household devices. Specifically, we converted the values into the operating time of a Phillips LED light bulb (10.5 W)<fnref n="5" />, making the energy data more relatable to developers and end users.

To ensure reproducibility and minimize biases, we followed the best practices outlined by *Ournani et al.* [38]. In particular, to ensure accurate measurements, we considered the following factors:

* We chose a CPU with a low TDP (15 W). CPUs with lower TDP values have less variability in power measurements [38].

* CPU performance options (C-States, Hyper-Threading and TurboBoost) significantly impact the standard deviation during energy consumption measurement [2, 38]. Therefore, we disabled these options in both the BIOS and OS.

<footnote n="1">¹https://luiscruz.github.io/2021/07/20/measuring-energy.html</footnote>

<footnote n="2">²https://github.com/powerapi-ng/jouleit</footnote>

<footnote n="3">³https://powerapi.org/</footnote>

<footnote n="4">⁴https://github.com/powerapi-ng/jouleit</footnote>

<footnote n="5">⁵Philips LED light bulb datasheet</footnote>
* The installed OS (Lubuntu) is a lightweight Ubuntu distribution, chosen to minimize its impact on the measurements. Additionally, we disabled the network service to avoid interference from network traffic [38].

Moreover, *Jouleit* also allows us to collect execution time data. This is done by capturing a timestamp (using the date command) immediately before executing the program and another timestamp right after the execution completes. The difference between these two timestamps gives the precise execution time of the program.

Finally, we used a Dell Latitude 7490 machine with an Intel Core i7-8650U processor, which has a Thermal Design Power (TDP) of 15 W. The machine is equipped with 32 GB of DDR4 RAM and runs Linux Lubuntu 22.04.2 LTS with kernel version 5.19.0-45-generic.

# 4 Methodology of the Experiment: Built-in Feature Reduction and Energy Consumption

This section describes our study on software systems with built-in feature reduction to evaluate their impact on energy consumption.

## 4.1 Subject Systems

To obtain a representative set of software systems with built-in feature reduction, we selected three configurable software systems: GNU [18], ToyBox [31], and BusyBox [54]. The GNU core programs include essential file, shell, and text manipulation utilities that are typically available on every operating system, which we refer to as *programs*. Examples of these programs include `mkdir`, which concatenates and write files, `ls`, which lists directory contents, and `mv`, which moves or renames files and directories. We chose these programs because they are well-known and used daily by millions of users. Additionally, they are often used to evaluate different debloating approaches in software engineering [4, 8, 21, 56]. Importantly, the programs in both ToyBox and BusyBox represent a deliberate application of feature reduction (i.e., built-in) of GNU programs. These alternative programs were specifically developed to reduce binary size, configuration space, and to simplify implementation, while improving execution time.

## 4.2 Pre-experiment Settings

First, we built all programs included by default in each set, specifically in the recent versions: GNU version 9.3, ToyBox version 0.8.9, and BusyBox version 1.36.0. Then, we extracted only the programs common to all three systems, resulting in a set of 75 shared programs. From this set, we selected 28 programs based on diversity in binary size and the number of configuration options.

Let $S$ represent the set of 28 selected subject programs. Each program $p \in S$ has its own executable in GNU, ToyBox, and BusyBox, differing in binary size and the number of run-time configuration options available. Next, we enumerated all configuration options for each implementation of $p$. For example, the cat executable is 185 KiB with 12 options in GNU, while in ToyBox, it is 18 KiB with 4 options, and in BusyBox, it is 18 KiB with 6 options.

## 4.3 Experiment Settings

Using the 28 selected subject programs, we measured both the energy consumption and execution time of each program. To measure energy consumption, we used *Jouleit*.

For each $p \in S$, we selected two valid configurations $c_1, c_2 \in C$ along with a valid input $i \in I$. Here, $C$ represents the configuration space of program $p$, encompassing all feasible configurations or potential combinations of configuration options, and $I$ denotes the set of possible inputs for the program. Configurations $c_1$ and $c_2$ were selected based on the availability of their configuration options in each of the respective implementations of $p$ within GNU, ToyBox, and BusyBox. Specifically, we used purposive sampling [34] to select two common configurations for each program, ranging from none to multiple options depending on the program. This selection was based on the documentation, our expertise, and a carefully chosen input $i$, when required. For instance, Listing 1 shows the `ls` program in GNU with configurations $c_1 = -R$ and $c_2 = -Ral$, and input = `/path/to/directory` used in our experiment. The same configurations and input(s) were then applied to the respective implementations of $p$ (e.g., of `ls`) in ToyBox and BusyBox.

### Listing 1: ./GNU/1s with 2 configurations and input used

Next, we compared the binary size and the number of run-time configuration options of the selected programs from GNU, ToyBox, and BusyBox. Using the implementation of GNU as the baseline, Figure 2 shows that each counterpart in ToyBox and BusyBox has a smaller binary size and fewer run-time options. On average, the 28 programs selected in ToyBox exhibit a 92% reduction in binary size and 64% fewer options, while in BusyBox, they show a 93% reduction in binary size and 66% fewer options compared to GNU. These data confirm that each selected program for the experiment undergoes a genuine *built-in feature reduction*.

To avoid side effects, all experiments were run 10 times sequentially as the only active processes on the workstation (see Section 3.3). Additionally, all subjects, configurations, and data are available online [52] for reproducibility.

# 5 Results of Built-in Feature Reduction

This section presents the results and discusses the findings related to our first set of research questions, namely $RQ_{1.1}$, $RQ_{1.2}$, and $RQ_{1.3}$. These questions examine the effects of built-in feature reduction on energy consumption, by exploring its correlation with other non-functional properties, such as the program's binary size, configuration options, and execution time.

## 5.1 Results on Energy Consumption

*General insights.* Table 1 shows the average energy consumption for each program in GNU, ToyBox, and BusyBox, along with the standard deviation (StD) for the 10 repetitions. To conserve space, the values in the table are presented in *joules* (J), even though the measurements were conducted in *micro-joules* (µJ).

Looking at Table 1, we observed that the majority of programs (uncolored) consume less than ≈ 7.5 J: specifically, 22 programs in GNU, 20 in ToyBox, and 20 in BusyBox. An energy consumption

<footnote n="1">1. $ ./GNU/1s -R /path/to/directory // First configuration</footnote>

<footnote n="2">2. $ ./GNU/1s -Ral /path/to/directory // Second configuration</footnote>
<figure><img src="image_4.png" /></figure>

<figure><img src="image_5.png" /><figcaption>Figure 2: 28 selected programs along with their respective binary size (left) and # options (right) in GNU, ToyBox, and BusyBox</figcaption></figure>

<table><caption>Table 1: Energy Consumption ± Standard Deviation (StD) in joules [J] for 28 programs with imposed feature reduction</caption><thead><tr><th>Program</th><th>GNU ± StD</th><th>ToyBox ± StD</th><th>Diff.%</th><th>BusyBox ± StD</th><th>Diff.%</th></tr></thead><tbody><tr><td>base64</td><td>0.35 ± 0.04</td><td>0.91 ± 0.04</td><td>160</td><td>0.43 ± 0.08</td><td>23.13</td></tr><tr><td>basename</td><td>0.29 ± 0.02</td><td>0.29 ± 0.01</td><td>-0.48</td><td>0.29 ± 0.02</td><td>-0.11</td></tr><tr><td>cat</td><td>2.13 ± 0.11</td><td>1517.43 ± 81</td><td>71284</td><td>37.56 ± 1.93</td><td>1667</td></tr><tr><td>chmod</td><td>1.54 ± 1.28</td><td>1.52 ± 1.26</td><td>-1.06</td><td>1.95 ± 1.71</td><td>26.78</td></tr><tr><td>cksum</td><td>11.39 ± 11.42</td><td>206.25 ± 212</td><td>1710</td><td>245.80 ± 253</td><td>2057</td></tr><tr><td>comm</td><td>55.07 ± 5.56</td><td>338.32 ± 286</td><td>514</td><td>120.87 ± 8.63</td><td>120</td></tr><tr><td>cp</td><td>108.85 ± 7.20</td><td>147.44 ± 56.97</td><td>35.46</td><td>111.25 ± 18.99</td><td>2.21</td></tr><tr><td>cut</td><td>2.21 ± 0.25</td><td>11.40 ± 0.72</td><td>416</td><td>4.93 ± 1.20</td><td>123</td></tr><tr><td>date</td><td>0.32 ± 0.02</td><td>0.32 ± 0.02</td><td>-0.02</td><td>0.31 ± 0.02</td><td>-1.00</td></tr><tr><td>dirname</td><td>0.32 ± 0.02</td><td>0.31 ± 0.02</td><td>-2.89</td><td>0.31 ± 0.02</td><td>-3.56</td></tr><tr><td>du</td><td>0.52 ± 0.23</td><td>0.52 ± 0.23</td><td>-0.90</td><td>0.49 ± 0.21</td><td>-6.24</td></tr><tr><td>echo</td><td>0.32 ± 0.02</td><td>0.31 ± 0.02</td><td>-3.29</td><td>0.31 ± 0.02</td><td>-5.02</td></tr><tr><td>expand</td><td>7.27 ± 0.33</td><td>0.50 ± 0.03</td><td>-93.09</td><td>14.57 ± 0.85</td><td>100</td></tr><tr><td>factor</td><td>0.32 ± 0.02</td><td>0.32 ± 0.02</td><td>-1.80</td><td>0.32 ± 0.02</td><td>-1.77</td></tr><tr><td>false</td><td>0.32 ± 0.02</td><td>0.32 ± 0.02</td><td>-1.68</td><td>0.31 ± 0.02</td><td>-4.63</td></tr><tr><td>head</td><td>0.32 ± 0.02</td><td>0.31 ± 0.02</td><td>-1.62</td><td>0.31 ± 0.02</td><td>-3.77</td></tr><tr><td>id</td><td>0.33 ± 0.02</td><td>0.31 ± 0.02</td><td>-4.49</td><td>0.31 ± 0.02</td><td>-6.01</td></tr><tr><td>link</td><td>0.32 ± 0.02</td><td>0.31 ± 0.02</td><td>-1.55</td><td>0.31 ± 0.02</td><td>-3.45</td></tr><tr><td>ln</td><td>0.32 ± 0.02</td><td>0.34 ± 0.02</td><td>4.10</td><td>0.31 ± 0.02</td><td>-5.38</td></tr><tr><td>logname</td><td>0.32 ± 0.02</td><td>0.31 ± 0.02</td><td>-3.58</td><td>0.31 ± 0.02</td><td>-3.82</td></tr><tr><td>ls</td><td>1.05 ± 0.47</td><td>3.49 ± 1.03</td><td>233</td><td>0.90 ± 0.22</td><td>-14.34</td></tr><tr><td>md5sum</td><td>118.60 ± 122</td><td>264.03 ± 271</td><td>123</td><td>143.15 ± 147</td><td>20.70</td></tr><tr><td>mkdir</td><td>0.31 ± 0.02</td><td>0.30 ± 0.02</td><td>-2.05</td><td>0.30 ± 0.01</td><td>-2.92</td></tr><tr><td>mv</td><td>0.31 ± 0.02</td><td>0.30 ± 0.02</td><td>-3.27</td><td>0.30 ± 0.02</td><td>-3.80</td></tr><tr><td>sort</td><td>95.54 ± 4.75</td><td>469.33 ± 25.61</td><td>391</td><td>318.30 ± 16.59</td><td>233</td></tr><tr><td>touch</td><td>0.30 ± 0.02</td><td>0.30 ± 0.01</td><td>-0.01</td><td>0.29 ± 0.02</td><td>-0.23</td></tr><tr><td>true</td><td>0.29 ± 0.02</td><td>0.29 ± 0.02</td><td>-1.33</td><td>0.29 ± 0.02</td><td>0.02</td></tr><tr><td>wc</td><td>454.69 ± 24</td><td>151.48 ± 32.48</td><td>-66.68</td><td>87.56 ± 6.07</td><td>-80.74</td></tr></tbody></table>

Energy-inefficient programs, Less Energy-efficient programs

Lower energy consumption, Higher energy consumption

Non-significant difference

of 7.5 J is equivalent to having a 10.5 W LED light bulb turned on for 0.72 seconds. These programs are considered as energy efficient according to our own categorization.

On the other hand, only 1 to 3 programs fall into the 10 - 100 J consumption range, making them less energy-efficient ( ). 10 J of energy consumption is equivalent to turning on a 10.5 W LED light

bulb for 0.95 seconds, while 100 J is equivalent to 9.52 seconds of use. Additionally, there are 3 energy-inefficient programs in GNU, 7 in ToyBox, and 5 in BusyBox, as they consume over 100 J ( ). Although the values differ across various realizations of the same program, only cp and md5sum programs consistently consume over 100 J in all three implementations. Although consuming less than 100 J in its original version, sort in ToyBox is the most energy-consuming program, consuming ≈ 469.33 J. This is equivalent to the energy consumed by a 10.5 W LED light bulb running for 44.7 seconds. It is noteworthy that the programs classifies as energy-inefficient exhibit large standard deviations, indicating that their energy consumption values are more spread out from the average. Among these programs, cksum, md5sum, and comm have over 100% StD (only in ToyBox), suggesting that the energy consumed in each run varies significantly from the average. Despite that we conducted multiple repetitions, identifying the precise factors influencing these deviations in energy consumption proved challenging.

Comparative analysis. As shown in Figure 2, the binary size and number of run-time options in the programs from GNU are higher than those in ToyBox and BusyBox. Therefore, using the programs in GNU as a baseline, we conducted a comparative analysis to determine whether the programs in ToyBox and BusyBox, with their reduced features, are more energy efficient than their counterparts in GNU. In the *Diff. %* columns of Table 1, we present the comparative analysis results. For each case, we use the Mann-Whitney U test [33] to assess the statistical significance of the observed differences. A program's difference is marked with the red line pattern (//) if it lacks statistical significance in either of the two cases (i.e., p-value above the significance level of 0.05). The computed p-values are available in the reproduction package [52].

The results show that 18 of the 28 programs (≈ 64%) in ToyBox consume less energy than their counterparts in GNU for the same configurations and inputs. Similarly, 17 of the 28 programs (≈ 61%) in BusyBox use less energy. However, only 2 programs in each system demonstrate statistically significant energy savings ( ). This indicates that most energy reductions, while present, are not strong enough to be considered statistically reliable (cf. negative values with //). Conversely, 10 programs (≈ 36%) in ToyBox and 11 programs (≈ 39%) in BusyBox consume more energy than their GNU counterparts. Among these, 7 programs in each system show
<table><caption>**Table 2:** Spearman correlation ($r_s$) of execution time, binary size, and number of options with energy consumption</caption><thead><tr><th rowspan="2"></th><th colspan="2">Energy/Size</th><th colspan="2">Energy/Options</th><th colspan="2">Energy/Exec. Time</th></tr><tr><th>r<sub>s</sub></th><th>p-value</th><th>r<sub>s</sub></th><th>p-value</th><th>r<sub>s</sub></th><th>p-value</th></tr></thead><tbody><tr><td>GNU</td><td>0.251</td><td>0.197</td><td>0.461</td><td>0.014</td><td>0.891</td><td>2.07e-10</td></tr><tr><td>ToyBox</td><td>0.350</td><td>0.068</td><td>0.392</td><td>0.039</td><td>0.966</td><td>1.02e-16</td></tr><tr><td>BusyBox</td><td>0.305</td><td>0.115</td><td>0.271</td><td>0.164</td><td>0.959</td><td>7.98e-16</td></tr></tbody></table>

No significant correlation (p-value> 0.05).

Interpretation of the $r_s$: ±0.9 – ±1.0 (very high); ±0.70 – ±0.90 (high); ±0.50 – ±0.70 (moderate); ±0.30 – ±0.50 (low); 0.00 – ±0.30 (negligible)

statistically significant energy increases (■), meaning that these differences are more robust and likely not to random variation. However, in 3 ToyBox programs and 4 BusyBox programs, the observed energy increases are not statistically significant (cf. positive values with ⌜). These results show that while most of the programs in ToyBox and BusyBox consume less energy compared to their counterparts in GNU, significant energy savings occur only in 7.14% of the cases. In contrast, 25% of the cases show statistically significant increases in energy consumption.

These initial insights suggest that reducing the binary size of an executable and the number of configuration options in a program does not necessarily lead to lower energy consumption.

## 5.2 Binary Size Impact

To explore the relationship between binary size and energy consumption, we calculated the Spearman correlation, which, unlike the Pearson correlation, does not require any normality assumption. The results are interpreted using Evans' rule [26]. This analysis encompassed the 28 programs in GNU, ToyBox, and BusyBox. Basically, we focus on determining the correlations between the binary size of the programs and their corresponding average energy consumption, as outlined in Figure 2 (left) and Table 1 (columns with StD), respectively.

The column *Energy/Size* in Table 2 presents the calculated correlations. Spearman coefficients range from 0.251 to 0.350. The highest correlations are in ToyBox and BusyBox, indicating a weak correlation between binary size and energy consumption in these programs. In contrast, the programs in GNU show a negligible correlation, suggesting that the relationship between binary size and energy consumption is insignificant. These findings, showing negligible to weak correlations, reinforce the initial insights and conclusions drawn from the comparative analysis in Section 5.1.

To determine whether the correlations are statistically significant, we also calculated the *p-value* with the significance level ($\alpha$) of 5% for each set of programs. The second column of *Energy/Size* in Table 2 shows the obtained values. All p-values are greater than 0.05 (with ⌜), indicating that the negligible correlations are not statistically significant. This suggests insufficient evidence to confidently claim a relationship between the program's binary sizes and their energy consumption. In contrast, since the Spearman p-value for ToyBox is close to the significance level of $\alpha$, we can conclude

that the weak correlation between program size and energy consumption in ToyBox is almost statistically significant.

**RQ1.1 insights:** Our finding, based on the analysis of 28 programs reduced using a built-in reduction approach, indicates a very weak correlation between binary size and energy consumption. This suggests that other factors have a more substantial influence on determining a program's energy consumption.

## 5.3 Number of Configuration Options Impact

Similarly, to assess the impact of configuration options on a program's energy consumption, we measured the correlation between the number of run-time configuration options (Figure 2, right) and its energy consumption given (Table 1, columns with StD).

The column *Energy/Options* in Table 2 presents the Spearman calculated correlations for all programs in GNU, ToyBox, and BusyBox. These coefficients, which represent the relationship between the number of run-time options and energy consumption, range from 0.271 to 0.461. Except in BusyBox, the coefficients for GNU and ToyBox show meaningful, though weak, relationships. These findings provide a contrast to the insights and conclusions drawn in Section 5.1.

Regarding statistical significance, we calculated the p-values with a significance level of $\alpha$ = 5%. The fifth column in Table 2 shows the obtained values. The p-values for GNU and ToyBox are below the significance level, indicating that the weak correlation in GNU and ToyBox are statistically significant. For BusyBox, the p-value exceeds $\alpha$ (with ⌜), suggesting that while there is a correlation between the run-time options and energy consumption, the evidence is not strong enough to confirm a meaningful relationship.

**RQ1.2 insights:** Based on our findings, reducing the number of runtime configuration options in an alternative implementation of a program does not necessarily lead to lower energy consumption. However, in some cases, there is a weak but statistically significant correlation between the number of options and energy consumption. This suggests that other factors may play a stronger role in determining a program's energy consumption.

## 5.4 Execution Time Impact

Due to the weak to negligible correlations observed between a program's binary size and energy consumption, as well as between the number of run-time configuration options and energy consumption, we conducted another investigation, specifically exploring the correlation between a program's *execution time* and its *energy consumption*. Our aim was to determine whether execution time influences energy consumption during a program's execution and to evaluate its consistency under built-in feature reduction.

The column *Energy/Exec. Time* in Table 2 shows the computed Spearman correlations for the three implementations of our 28 subjects. They range from 0.891 to 0.966, indicating a consistently high or nearly perfect correlation between a program's execution time and its energy consumption. The last column in Table 2 also presents the associated p-values. All of them are between 1.02·10⁻¹⁶
<table><caption>Table 3: Binary sizes for six programs before (bloated, B. size) and after debloating (D. size) with Chisel, Cov, and Debop. Energy consumption of programs (in joules [J]) is reported as mean ± standard deviation (StD)</caption><thead><tr><th>Program</th><th>B. size (KiB)</th><th>D. size (KiB)</th><th>Bloated ± StD</th><th>Chisel ± StD</th><th>Diff.%</th><th>Cov ± StD</th><th>Diff.%</th><th>Debop ± StD</th><th>Diff.%</th></tr></thead><tbody><tr><td>date-8.21</td><td>92.03</td><td>33.54</td><td>0.288 ± 0.014</td><td>0.284 ± 0.010</td><td>-1.30</td><td>0.284 ± 0.009</td><td>-1.24</td><td>0.284 ± 0.010</td><td>-1.24</td></tr><tr><td>grep-2.4.2</td><td>158.83</td><td>93.42</td><td>0.317 ± 0.020</td><td>0.457 ± 0.021</td><td>44.22</td><td>0.315 ± 0.018</td><td>-0.58</td><td>0.315 ± 0.018</td><td>-0.53</td></tr><tr><td>gzip-1.3</td><td>101.71</td><td>66.72</td><td>0.335 ± 0.013</td><td>0.549 ± 0.022</td><td>64.03</td><td>0.332 ± 0.016</td><td>-0.87</td><td>0.332 ± 0.008</td><td>-0.91</td></tr><tr><td>mkdir-5.2.1</td><td>48.20</td><td>21.64</td><td>0.289 ± 0.016</td><td>0.288 ± 0.014</td><td>-0.50</td><td>0.288 ± 0.012</td><td>-0.63</td><td>0.288 ± 0.011</td><td>-0.67</td></tr><tr><td>printtokens2</td><td>20.68</td><td>20.68</td><td>0.282 ± 0.009</td><td>0.281 ± 0.012</td><td>-0.25</td><td>0.285 ± 0.021</td><td>1.11</td><td>0.282 ± 0.013</td><td>-0.08</td></tr><tr><td>sed-4.1.5</td><td>170.38</td><td>107.05</td><td>0.286 ± 0.010</td><td>0.289 ± 0.015</td><td>1.12</td><td>0.290 ± 0.022</td><td>1.69</td><td>0.287 ± 0.014</td><td>0.63</td></tr></tbody></table>

<figure><img src="image_6.png" /></figure>

Lower energy consumption

<figure><img src="image_7.png" /></figure>

Higher energy consumption

<figure><img src="image_8.png" /></figure>

Non-significant difference on the consumed energy

and $2.07 \cdot 10^{-10}$, significantly below the significance level or $\alpha = 5\%$. This indicates that the strong correlations between execution time and energy consumption are statistically significant, suggesting similar relationships may exist in other programs as well.

**RQ1.3 insights:** The relationship between energy consumption and execution time remains consistent despite built-in feature reduction. Alternative implementations, such as BusyBox and ToyBox, exhibit a stronger correlation between energy consumption and execution time compared to their counterparts in GNU.

# 6 Methodology of the Experiment: On-demand Feature Reduction and Energy Consumption

This section describes our second study on systems with on-demand feature reduction to evaluate their impact on energy consumption.

## 6.1 Subject Systems

To establish a representative set of software with on-demand feature reduction, we utilized open-access artifacts from Xin et al. [57], which include debloated programs produced by three state-of-the-art debloating tools [8]. These used tools and programs are widely recognized as benchmarks in debloating studies (e.g., [8, 32, 57]). Specifically, we selected 6 GNU programs debloated by Chisel, Debop, and Cov tools, focusing on those that we could successfully compile and execute with the provided training input and configuration. Notably, some of the compilation challenges we encountered are also highlighted in [57]. These tools employ debloating techniques that operate at the source code level. Each of them requires both a bloated program and a specification of desired or undesired features (i.e., a usage profile with configuration options and an input) to produce debloated artifacts. This approach enables controlled and on-demand feature reduction.

To strengthen our experiment, we not only applied three debloating tools, but also selected six programs similar to those in our first experiment. This enables us to provide comparable results. Table 3 presents their original binary size (i.e., before debloat) and reduced binary size (i.e., after debloat) in Kibibyte (KiB).

## 6.2 Experiment Settings

For each of the 6 programs, we measured energy consumption and execution time in both bloated and debloated states.

We first extracted and compiled the source code of both the bloated and debloated variants of the 6 subject programs. Each program had three debloated variants, one produced by each of the debloating tools. In addition, multiple usage profiles (i.e., configurations with inputs) were available. For each debloated variant we considered two different configurations, as in our first experiment (i.e., same program, same debloating technique, but two different input profiles per program). Each profile (configuration and input) used in our study was selected based on two criteria. First, the profile that produced correct output for all debloated variants of the program. Secondly, similar to the first experiment, we used purposive sampling [34] to select two profiles that represent the program's typical usage based on its documentation.

Thus, we measured the energy consumption of the 6 bloated programs and their 18 debloated counterparts (6 * 3), following the same procedure and measurement setup described in Section 3.3. To avoid side effects, all experiments were run sequentially 10 times as the only processes on the workstation.

# 7 Results of On-demand Feature Reduction

This section presents the results and findings related to on-demand feature reduction research questions, $RQ_{2.1}$ and $RQ_{2.2}$, focusing on how binary size and execution time affect energy consumption.

## 7.1 Results on Energy Consumption

The columns labeled ... ± StD in Table 3 show the average energy consumption of software programs both before and after debloating. For example, the original grep (bloated) consumes 0.317 J, while its debloated variant using the Cov tool consumes slightly less, about 0.315 J, equivalent to 0.03 seconds of LED light usage (10.5 W).

**General insights.** Table 3 shows that both bloated and debloated programs consume less than 1 J, which is consistent with the trend observed in our first experiment with programs featuring built-in feature reduction. The small standard deviation across our 10 repetitions suggests that the energy consumption values are consistent around the average for all bloated and debloated programs.

**Comparative analysis.** Similarly, we performed a comparative analysis to determine if the first experiment's findings hold for programs with on-demand feature reduction. Specifically, we compared the binary size and energy consumption of programs before and after debloating. The columns labeled *Diff.*% in Table 3 show the percentage change in energy consumption for debloated programs,
compared to their bloated variants, which serve as the baseline. This shows whether energy consumption increased or decreased after debloating. The statistical significance of the difference is also computed. A program's difference is highlighted with a red diagonal line pattern (//) if it lacks statistical significance in either of the two scenarios, as determined by the Mann-Whitney U test [33].

All debloated programs have smaller binary size. Regarding energy consumption, 12 out of 18 debloated programs (66.7%) show a decrease. However, as in the first experiment, most of the differences in energy consumption are not statistically significant. Specifically, 4 out of 6 programs debloated with Chisel, and all programs debloated with Cov and Debop, show no significant differences (//). Only 2 out of 6 programs debloated with Chisel demonstrate significant differences (■), with energy consumption increased by ≈ 44% and ≈ 64%, respectively. Moreover, no debloated program consumes significantly less energy (■) than its bloated counterparts. This reinforces our conclusion from the first experiment that reducing a program's binary size through debloating does not necessarily lead to lower energy consumption. The differences observed are largely non-significant, and when significant, they tend towards higher energy consumption, as are the two cases with Chisel.

## 7.2 Binary Size Impact

Similarly to the first experiment, we calculated the correlation using Spearman coefficients [26]. This analysis included all 6 programs, both bloated and debloated variants of them, with a focus on the correlations between binary size and average energy consumption. We found that the correlation between binary size and energy consumption in bloated programs was 0.314, indicating a weak relationship. In contrast, the debloated programs showed a moderate correlation of 0.60, as seen in the Energy/Binary Size column in Table 4. However, the p-values for all correlations exceed the significance threshold of $\alpha = 0.05$, suggesting that the observed correlations are not statistically significant. This indicates that there is not enough evidence to show a meaningful relationship between binary size and energy consumption in the debloated programs.

**RQ2.1 insights:** Reducing a program's binary size through debloating techniques does not consistently result in lower energy consumption. In most cases, the differences in energy usage between the debloated and original variants are statistically insignificant, and when significant, energy consumption is sometimes higher in the debloated variants.

## 7.3 Execution Time Impact

Due to the weak correlation between binary size and energy consumption in both bloated and debloated programs, we extended our investigation to explore whether execution time exhibits a stronger correlation, as observed in our first experiment. The column Energy/Exec. Time in Table 4 shows that the correlations computed for the 6 subjects debloated by three tools fall between 0.886 and 1.00. In bloated programs, the correlation between execution time and energy consumption was 1.00, signifying a perfect relationship. For debloated programs, the results demonstrate a high or nearly perfect correlation between execution time and energy consumption. Furthermore, the p-values listed in the same column in Table 4

<table><caption>Table 4: The Spearman correlation ($r_s$) between energy consumption and both execution time and binary size</caption><thead><tr><th></th><th colspan="2">Energy/Binary Size</th><th colspan="2">Energy/Exec. Time</th></tr><tr><th></th><th>r<sub>s</sub></th><th>p-value</th><th>r<sub>s</sub></th><th>p-value</th></tr></thead><tbody><tr><td><i>bloated</i></td><td>0.314</td><td>0.544</td><td>1.000</td><td>0.000</td></tr><tr><td>Chisel</td><td>0.600</td><td>0.208</td><td>1.000</td><td>0.000</td></tr><tr><td>Cov</td><td>0.600</td><td>0.208</td><td>0.886</td><td>0.019</td></tr><tr><td>Debop</td><td>0.600</td><td>0.208</td><td>0.943</td><td>0.005</td></tr></tbody></table>

are significantly below the $\alpha = 5\%$ threshold. This indicates that the strong observed correlation between energy consumption and execution time in debloated programs is statistically significant, suggesting that it may also hold true for other software programs.

**RQ2.2 insights:** Similar to the first experiment, there is a strong and consistent correlation between execution time and energy consumption. This indicates that energy consumption in software is closely linked to the program's execution time. Regardless of debloating, optimizing execution time emerges as a critical factor in achieving energy-efficient software.

# 8 In-Depth Analysis, Discussion, and Insights

## 8.1 Summary of Key Findings

Our study reveals that feature reduction does not consistently lead to lower energy consumption. In most cases, the impact of feature reduction on energy consumption were statistically insignificant. Specifically, in built-in alternatives, 4 out of 56 cases showed a significant reduction, 14 a significant increase, and 38 had no significant difference. In debloated programs, 2 out of 18 cases showed a significant increase in energy consumption, while 16 had no significant change. Basically, when differences were significant, they tended to result in increased energy consumption.

We found that there is a consistent and strong correlation between energy consumption and execution time across both types of reduced programs. This suggests that reducing execution time is an effective strategy for improving energy efficiency, regardless of feature reduction. Moreover, our findings align with a recent comparative evaluation of software debloating tools [8], which reports that debloating techniques often have no significant impact on execution time, and when they do, the effect tends to be negative, consistent with our observations regarding energy consumption.

Debloating approaches leverage feature reduction to optimize non-functional properties, generally binary size or attack surface. However, this mono-objective optimization can negatively affect other non-functional properties. For instance, debloating with a focus on reducing binary size may increase the attack surface [56].

## 8.2 Unintended Energy Impacts of Debloating

In light of these findings, it is essential to investigate why some debloating techniques inadvertently lead to increased energy consumption. One plausible explanation is that when debloating focuses solely on reducing binary size or attack surface, it might also eliminate code segments that contribute to energy efficiency. To
<figure><img src="image_9.png" /><figcaption>Listing 2: Optimizing code removal by Chisel: ■ LoC deleted but executed in bloated; □ LoC newly executed in debloated</figcaption></figure>

<figure><img src="image_10.png" /></figure>

explore this, we analyzed in-depth the executed code of the two debloated programs with significant increases: grep-2.4.2 and gzip-1.3 (cf. marked with ■ in Table 3). Both were debloated using Chisel, a mono-objective debloating tool focusing on reducing binary size. To understand this difference, we analyzed the execution coverage using gcov 6 for both bloated and debloated variants of these programs. We observed that there is a reduction in executed lines of code for grep (-10.5%) and gzip (-11.4%) in the debloated variants compared to their bloated counterparts. This reduction seems counterintuitive given the increased energy consumption. But, aligning code coverage reports with code *diffs* revealed that Chisel removed certain optimizing code segments.

Specifically, in grep-2.4.2 (Listing 2), we observed that removing a conditional linked to the intentionally debloated `--quiet` option inadvertently caused additional code execution. For instance, line 4, which previously prevented some unnecessary function calls, was correctly removed with the removed option, but this resulted in line 5 being executed 76 times in the debloated program variant. Whereas, in gzip-1.3 (Listing 2), an early return removal caused also some unnecessary computation. While the method was invoked fewer times in the debloated variant (once versus seven), we think that the lack of early return logic could lead to inefficiency in different contexts, negatively affecting energy consumption.

These observations show the need for an in-depth investigation into the impact of removing code snippets which may play a role in optimizing energy consumption. Additional cases that we found are provided in the reproduction package. An interesting hypothesis to explore is how debloating techniques, which aim to reduce binary size, may unintentionally remove optimizing code, leading to increased energy consumption despite reduced code execution.

## 8.3 `ecv`: Energy Consumption Visualizer

Both built-in and on-demand feature reduction are generally not conducted with the aim to optimize energy consumption. Thus, providing information on energy consumption to developers is crucial when selecting an alternative implementation or using a debloated tool. To address this, we developed a tool called `ecv` [52]. It uses progress bars to visually represent a software program's energy consumption. Additionally, below the progress bar, `ecv` provides information about how long the program's energy consumption could power familiar devices, such as LED light bulbs (including HDD Seagate BarraCuda, 5 W and NVIDIA GPU RTX4080, 320 W 7).

<figure><img src="image_11.png" /><figcaption>Listing 3: Measuring energy consumption of `ls -la` command (program with a given input) with 5 repeats using `ecv` tool</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>Figure 3: Output of `ecv` for the program `ls -la` in Listing 3</figcaption></figure>

Listing 3 demonstrates how to measure energy consumption of the `ls -la` command using the `--measure` option of `ecv`, with five repetitions specified by the `--repeat 5` option. Figure 3 displays the corresponding output, including details on how long the measured energy could power three common electronics.

`ecv` offers two usage scenarios: one for developers and one for end-users. For developers working on configurable systems, the tool helps measure and track their programs' energy consumption as the software evolves. On the other hand, end-users can use `ecv` to compare alternative programs based on their energy consumption, as demonstrated in our initial experiment. We believe that this enables users to make more informed decisions, particularly when choosing between alternative program implementations. Furthermore, `ecv` is open source and available for evaluation [52]. Its repository includes additional usage examples to explore its capabilities.

## 8.4 Towards Energy-Aware Debloating

Our exploratory study shows the promising potential of debloating techniques to reduce energy consumption, while also revealing the challenges to fully realize this goal. While it may seem intuitive that removing code, potentially executed but associated with non-necessary feature for a given profile would reduce energy consumption, our observations suggest the contrary. We identify snippets where debloating tools removes potential optimizing code in terms of energy efficiency, opening the way for approach preserving these codes. Multi-objective approaches, such as the one proposed by Debop, which simultaneously optimizes for binary size and attack surface, represent a promising direction for further exploration. Researchers might explore and investigate the configuration space and its relationship with energy consumption, either to predict execution time or to identify the most promising configuration options to debloat when considering energy. In addition, compiler parameter space optimization techniques [9] could also be leveraged to select configurations that have a positive impact on energy consumption.

Finally, researchers can also leverage `ecv` to identify among the alternative programs those with the lowest energy consumption and further investigate the reasons behind it, beyond binary size and configuration options. For example, energy efficiency could be influenced by the libraries used, or the algorithms employed.

<footnote n="6">6 Code coverage analysis tool - gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html</footnote>

<footnote n="7">7 Seagate BarraCuda 3.5" datasheet and NVIDIA RTX4080 datasheet</footnote>
## 9 Threats to Validity

**Internal threats.** In the initial experiment, energy consumption measurements were based on two configurations for each program. One potential threat is the selection bias, meaning the results may have been influenced by the specific configurations chosen. However, we opted for the most commonly used configurations to ensure that the measured energy consumption reflected typical usage for these programs. Another potential threat is choice of input data for each program, as input can affect energy consumption. We mitigated this by selecting representative inputs and keeping them constant across similar programs. In future work, we plan to expand our investigation by varying inputs and configurations to explore their impact on energy consumption. Finally, we had to compile both the bloated and particularly the debloated program variants provided by Xin et al. [57]. Many of the debloated programs failed to compile without segmentation faults (segfaults), so we included only those that worked to ensure the results were unbiased.

**External threats.** Our experiments focus on a specific set of programs, namely GNU, ToyBox, and BusyBox programs written in C. Although these programs are widely used in evaluations of debloating approaches and other studies, recent research has shown that energy consumption can vary significantly between programming languages [17, 28, 42]. Thus, we cannot generalize our findings to feature reduction in configurable software systems implemented in other languages or to systems with medium-to-large binary sizes and configuration spaces, such as Linux or Chromium [6, 44].

## 10 Related Work

This work intersects three research fields, namely configurable software systems, software bloat, and green computing.

**Configurable software systems and debloating.** Several studies have investigated debloating techniques on configurable systems. Ahmad et al. [3] proposed an approach to debloat code based on user-provided command line arguments and application-specific configuration files. Sharif et al. [48] developed an approach that leverages user-provided configuration data to specialize an application to its deployment context. Heo et al. [21] improved on previous work by using a novel reinforcement learning based approach to accelerate the search for debloated program and scale to large applications. Xin et al. [56] proposed a general multi-objective optimization approach for debloating. Xin et al. [57] studied the trade-offs between generality and reduction in software debloating. Tèrnava et al. [51] examined how the run-time configuration space affects binary size, attack surface, and execution time. Moreover, two recent surveys by Alhanahnah et al. [4] and Brown et al. [8] provide an overview of existing debloating approaches and tools developed over the past two decades. However, none of these studies has explored the impact of feature reduction on energy consumption.

**Software product lines and green computing.** Some studies measure the correlation between system execution time and energy consumption, focusing on adjusting rather than removing runtime configuration options [55]. In our case, we aim to reduce binary size by debloating and observe the system's footprint and its correlation with energy consumption. Sahin et al. [46] have investigated

how different types of refactoring impact energy consumption, using hardware instrumented measurements. They demonstrate that refactoring significantly affects energy consumption, though this effect can either increase or decrease energy usage depending on the application and execution platform. Guégain et al. [19] have explored energy consumption in software product lines, proposing a method to measure energy usage in such contexts. Using a T-wise algorithm, they produce 602 configurations of RobocodeSPL and measured the consumption for each, identifying the most energy-efficient ones. With this method, Guégain et al. [19] identified some configurations with a reduction in consumption of at least 40%. While their approach is based on SPL, it does not take into consideration feature reduction. Islam et al. [24] measured the energy consumption of individual features by slicing the source code associated with each feature, then monitoring energy consumption. This approach works well for individual features but does not consider interactions between them. Other works are focused on power consumption of specific code patterns or "energy hotspots" (e.g., [35, 41]). In 2015, Noureddine et al. [36] proposed a method for identifying and evaluating high energy consuming spots in Java source code. Pereira et al. [41] developed a method to locate inefficient source code fragments, demonstrating that developers using their technique improved energy efficiency by 43% on average. Like Islam et al. [24], these two approaches do not take the interactions between features into account. To the best of our knowledge, our study is the first to investigate the effect of feature reduction on energy consumption of configurable systems.

## 11 Conclusion and Perspectives

This paper presented a novel exploratory study on the effect of built-in and on-demand feature reduction of configurable systems on energy consumption. We found weak and mostly no significant correlations between energy consumption and factors such as binary size or the number of configuration options in software systems. This suggests that smaller binaries and fewer options do not necessarily lead to lower energy consumption. Interestingly, a given feature in a built-in reduced software system, similarly in an on-demand debloated software system, is more likely consuming more than in the original configurable software system. However, execution time showed a strong and significant link to energy consumption, indicating that its optimization is the key to making debloated software more efficient in terms of energy.

While traditional debloating techniques aim to remove unnecessary features to minimize binary size to reduce the attack surface, our study provides evidence for a new research direction: developing debloating strategies that prioritize energy efficiency and execution time, shifting the focus from size and security to sustainability and performance. In addition, analyzing long-term energy consumption in real-world usage, such as widely deployed tools like coreutils, can identify patterns and usage contexts where energy costs are highest. These insights can directly inform and motivate energy-aware debloating techniques by focusing on features with most energy-intensive in practice and therefore promising candidates for removal or optimization.
References

[1] Mathieu Acher, Hugo Martin, Luc Lesoil, Arnaud Blouin, Jean-Marc Jézéquel, Djamel Eddine Khelladi, Olivier Barais, and Juliana Alves Pereira. 2022. Feature Subset Selection for Learning Huge Configuration Spaces: The Case of Linux Kernel Size. In *Proceedings of the 26th ACM International Systems and Software Product Line Conference - Volume A* (Graz, Austria) (SPLC '22). Association for Computing Machinery, New York, NY, USA, 85–96. https://doi.org/10.1145/3546932.3546997

[2] Bilge Acun, Phil Miller, and Laxmikant V. Kale. 2016. Variation Among Processors Under Turbo Boost in HPC Systems. In *Proceedings of the 2016 International Conference on Supercomputing (Istanbul, Turkey) (ICS '16)*. Association for Computing Machinery, New York, NY, USA, Article 6, 12 pages. https://doi.org/10.1145/2925426.2926289

[3] Aatira Anum Ahmad, Abdul Rafae Noor, Hashim Sharif, Usama Hameed, Shoaib Asif, Mubashir Anwar, Ashish Gehani, Fareed Zaffar, and Junaid Haroon Siddiqui. 2022. Trimmer: An Automated System for Configuration-Based Software Debloating. *IEEE Transactions on Software Engineering* 48, 9 (2022), 3485–3505. https://doi.org/10.1109/TSE.2021.3095716

[4] Mohannad Alhanahnah, Yazan Boshmaf, and Ashish Gehani. 2024. SoK: Software Debloating Landscape and Future Directions. In *Proceedings of the 2024 Workshop on Forming an Ecosystem Around Software Transformation* (Salt Lake City, UT, USA) (FEAST '24). Association for Computing Machinery, New York, NY, USA, 11–18. https://doi.org/10.1145/3689937.3695792

[5] Peter Bambazek, Iris Groher, and Norbert Seyff. 2022. Sustainability in Agile Software Development: A Survey Study among Practitioners. In *2022 International Conference on ICT for Sustainability (ICT4S)*. 13–23. https://doi.org/10.1109/ICT4S55073.2022.00013

[6] Peter Beverloo. 2020-08-12. List of Chromium Command Line Switches. https:// peter.sh/experiments/chromium-command-line-switches/.

[7] Aurélien Bourdon, Adel Noureddine, Romain Rouvoy, and Lionel Seinturier. 2013. PowerAPI: A Software Library to Monitor the Energy Consumed at the Process-Level. *ERCIM News* 92 (Jan. 2013), 43–44. https://inria.hal.science/hal-00772454

[8] Michael D. Brown, Adam Meily, Brian Fairservice, Akshay Sood, Jonathan Dorn, Eric Kilmer, and Ronald Eytchison. 2024. A Broad Comparative Evaluation of Software Debloating Tools. In *33rd USENIX Security Symposium (USENIX Security 24)*. USENIX Association, Philadelphia, PA, 3927–3943. https://www.usenix.org/ conference/usenixsecurity24/presentation/brown

[9] Tamim Burgstaller, Damian Garber, Viet-Man Le, and Alexander Felfernig. 2024. Optimization Space Learning: A Lightweight, Noniterative Technique for Compiler Autotuning. In *Proceedings of the 28th ACM International Systems and Software Product Line Conference* (Dommeldange, Luxembourg) (SPLC '24). Association for Computing Machinery, New York, NY, USA, 36–46. https://doi.org/10.1145/3646548.3672588

[10] Shaiful Alam Chowdhury and Abram Hindle. 2016. GreenOracle: Estimating Software Energy Consumption With Energy Measurement Corpora. In *Proceedings of the 13th International Conference on Mining Software Repositories* (Austin, Texas) (MSR '16). Association for Computing Machinery, New York, NY, USA, 49–60. https://doi.org/10.1145/2901739.2901763

[11] Marco Couto, Paulo Borba, Jácome Cunha, João Paulo Fernandes, Rui Pereira, and João Saraiva. 2017. Products go Green: Worst-Case Energy Consumption in Software Product Lines. In *Proceedings of the 21st International Systems and Software Product Line Conference - Volume A* (Sevilla, Spain) (SPLC '17). Association for Computing Machinery, New York, NY, USA, 84–93. https://doi.org/10.1145/3106195.3106214

[12] Marco Couto, João Paulo Fernandes, and João Saraiva. 2021. Statically analyzing the energy efficiency of software product lines. *Journal of Low Power Electronics and Applications* 11, 1 (2021), 13. https://doi.org/10.3390/jlpea11010013

[13] Howard David, Eugene Gorbatov, Ulf R. Hanebutte, Rahul Khanna, and Christian Le. 2010. RAPL: Memory Power Estimation and Capping. In *Proceedings of the 16th ACM/IEEE International Symposium on Low Power Electronics and Design* (Austin, Texas, USA) (ISLPED '10). Association for Computing Machinery, New York, NY, USA, 189–194. https://doi.org/10.1145/1840845.1840883

[14] João De Macedo, Rui Abreu, Rui Pereira, and João Saraiva. 2022. WebAssembly versus JavaScript: Energy and Runtime Performance. In *2022 International Conference on ICT for Sustainability (ICT4S)*. 24–34. https://doi.org/10.1109/ICT4S55073.2022.00014

[15] Hugues Ferreboeuf, Françoise Berthoud, Philippe Bihouix, Pierre Fabre, Daniel Kaplan, Laurent Lefèvre, Alexandre Monnin, Olivier Ridoux, Samuli Vaija, Marc Vautier, Alain Ducass, Xavier Verne, Maxime Efoui-Hess, and Zeynep Kahraman. 2019. Lean ICT: Towards digital sobriety. https://theshiftproject.org/app/uploads/2025/04/Lean-ICT-Report_The-Shift-Project_2019.pdf

[16] Gerhard Fettweis and Ernesto Zimmermann. 2008. ICT: Energy Consumption-Trends and Challenges. In *Proceedings of the 11th International Symposium on Wireless Personal Multimedia Communications, Vol. 2*. Lapland, Finland, 6. https://api semanticscholar org/ CorpusID:9129930

[17] Stefanos Georgiou, Maria Kechagia, and Diomidis Spinellis. 2017. Analyzing Programming Languages' Energy Consumption: An Empirical Study. In *Proceedings of the 21st Pan-Hellenic Conference on Informatics (Larissa, Greece) (PCI '17)*.

Association for Computing Machinery, New York, NY, USA, Article 42, 6 pages. https://doi.org/10.1145/3139367.3139418

[18] GNU. [n. d.]. GNU Core Utilities. https://www.gnu.org/software/coreutils/

[19] Édouard Gué gain, Clément Quinton, and Romain Rouvoy. 2021. On Reducing the Energy Consumption of Software Product Lines. In *Proceedings of the 25th ACM International Systems and Software Product Line Conference - Volume A* (Leicester, United Kingdom) (SPLC '21). Association for Computing Machinery, New York, NY, USA, 89–99. https://doi.org/10.1145/3461001.3471142

[20] María Gutiérrez, Ma Ángeles Moraga, and Félix García. 2022. Analysing the Energy Impact of Different Optimisations for Machine Learning Models. In *2022 International Conference on ICT for Sustainability (ICT4S)*. 46–52. https://doi.org/10.1109/ICT4S55073.2022.00016

[21] Kihong Heo, Woosuk Lee, Pardis Pashakhanloo, and Mayur Naik. 2018. Effective Program Debloating via Reinforcement Learning. In *Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security* (Toronto, Canada) (CCS '18). Association for Computing Machinery, New York, NY, USA, 380–394. https://doi.org/10.1145/3243734.3243838

[22] Abram Hindle, Alex Wilson, Kent Rasmussen, E. Jed Barlow, Joshua Charles Campbell, and Stephen Romansky. 2014. GreenMiner: A Hardware Based Mining Software Repositories Software Energy Consumption Framework. In *Proceedings of the 11th Working Conference on Mining Software Repositories* (Hyderabad, India) (MSR '2014). Association for Computing Machinery, New York, NY, USA, 12–21. https://doi.org/10.1145/2597073.2597097

[23] Gerard J. Holzmann. 2015. Code Inflation. http://spinroot.com/gerard/pdf/Code_Inflation.pdf. Accessed: 2025-04-20.

[24] Syed Islam, Adel Noureddine, and Rabih Bashroush. 2016. Measuring Energy Footprint of Software Features. In *2016 IEEE 24th International Conference on Program Comprehension (ICPC)*. 1–4. https://doi.org/10.1109/ICPC.2016.7503726

[25] Mathilde Jay, Vladimir Ostapenco, Laurent Lefèvre, Denis Trystram, Anne-Cécile Orgerie, and Benjamin Fichel. 2023. An Experimental Comparison of Software-Based Power Meters: Focus on CPU and GPU. In *2023 IEEE/ACM 23rd International Symposium on Cluster, Cloud and Internet Computing (CCGrid)*. 106–118. https://doi.org/10.1109/CCGrid57682.2023.00020

[26] Maurice George Kendall. 1948. Rank Correlation Methods. (1948).

[27] Kashif Nizam Khan, Mikael Hirki, Tapio Niemi, Jukka K. Nurminen, and Zhonghong Ou. 2018. RAPL in Action: Experiences in Using RAPL for Power Measurements. *ACM Trans. Model. Perform. Eval. Comput. Syst.* 3, 2, Article 9 (March 2018), 26 pages. https://doi.org/10.1145/3177754

[28] Lukas Koedijk and Ana Oprescu. 2022. Finding Significant Differences in the Energy Consumption when Comparing Programming Languages and Programs. In *2022 International Conference on ICT for Sustainability (ICT4S)*. 1–12. https://doi.org/10.1109/ICT4S55073.2022.00012

[29] Masanari Kondo, Cor-Paul Bezemer, Yasutaka Kamei, Ahmed E Hassan, and Osamu Mizuno. 2019. The Impact of Feature Reduction Techniques on Defect Prediction Models. *Empirical Software Engineering* 24 (2019), 1925–1963. https://doi.org/10.1007/s10664-018-9679-5

[30] Elias Kuiter, Chico Sundermann, Thomas Thüm, Tobias Hess, Sebastian Krieter, and Gunter Saake. 2025. How Configurable is the Linux Kernel? Analyzing Two Decades of Feature-Model History. *ACM Trans. Softw. Eng. Methodol.* (April 2025). https://doi.org/10.1145/3729423 Just Accepted.

[31] Robert Landley and et al. [n. d.]. ToyBox. http://landley.net/toybox/about.html

[32] Bo Lin, Shangwen Wang, Yihao Qin, Liqian Chen, and Xiaoguang Mao. 2025. Large Language Models-Aided Program Debloating. *arXiv preprint arXiv:2503.08969* (2025). https://doi.org/10.48550/arXiv.2503.08969

[33] H. B. Mann and D. R. Whitney. 1947. On a Test of Whether one of Two Random Variables is Stochastically Larger than the Other. *The Annals of Mathematical Statistics* 18, 1 (1947), 50–60. http://www.jstor.org/stable/2236101

[34] B Mattew Miles and Michael A Huberman. 1994. *An Expanded Sourcebook: Qualitative Data Analysis*. Sage publications.

[35] Adel Noureddine, Romain Rouvoy, and Lionel Seinturier. 2013. A Review of Energy Consumption Approaches. *SIGOPS Oper. Syst. Rev.* 47, 3 (Nov. 2013), 42–49. https://doi.org/10.1145/2553070.2553077

[36] Adel Noureddine, Romain Rouvoy, and Lionel Seinturier. 2015. Monitoring Energy Hotspots in Software: Energy Profiling of Software Code. *Automated Software Engineering* 22 (2015), 291–332. https://doi.org/10.1007/s10515-014-0171-1

[37] Zakaria Ournani, Mohammed Chakib Belgaid, Romain Rouvoy, Pierre Rust, and Joël Penhoat. 2021. Evaluating the Impact of Java Virtual Machines on Energy Consumption. In *Proceedings of the 15th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) (Bari, Italy) (ESEM '21)*. Association for Computing Machinery, New York, NY, USA, Article 15, 11 pages. https://doi.org/10.1145/3475716.3475774

[38] Zakaria Ournani, Mohammed Chakib Belgaid, Romain Rouvoy, Pierre Rust, Joel Penhoat, and Lionel Seinturier. 2020. Taming Energy Consumption Variations In Systems Benchmarking. In *Proceedings of the ACM/SPEC International Conference on Performance Engineering* (Edmonton AB, Canada) (ICPE '20). Association for Computing Machinery, New York, NY, USA, 36–47. https://doi.org/10.1145/3358960.3379142
[39] Zakaria Ournani, Romain Rouvoy, Pierre Rust, and Joel Penhoat. 2020. On Reducing the Energy Consumption of Software: From Hurdles to Requirements. In *Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) (Bari, Italy) (ESEM '20)*. Association for Computing Machinery, New York, NY, USA, Article 14, 12 pages. https://doi.org/10.1145/3382494.3410678

[40] Candy Pang, Abram Hindle, Bram Adams, and Ahmed E. Hassan. 2016. What Do Programmers Know about Software Energy Consumption? *IEEE Software 33*, 3 (2016), 83–89. https://doi.org/10.1109/MS.2015.83

[41] Rui Pereira, Tiago Carção, Marco Couto, Jácome Cunha, João Paulo Fernandes, and João Saraiva. 2020. SPELLing Out Energy Leaks: Aiding Developers Locate Energy Inefficient Code. *Journal of Systems and Software* 161 (2020), 110463. https://doi.org/10.1016/j.jss.2019.110463

[42] Rui Pereira, Marco Couto, Francisco Ribeiro, Rui Rua, Jácome Cunha, João Paulo Fernandes, and João Saraiva. 2021. Ranking Programming Languages by Energy Efficiency. *Science of Computer Programming* 205 (2021), 102609. https://doi.org/10.1016/j.scico.2021.102609

[43] Gustavo Pinto, Fernando Castor, and Yu David Liu. 2014. Mining Questions About Software Energy Consumption (MSR 2014). Association for Computing Machinery, New York, NY, USA, 22–31. https://doi.org/10.1145/2597073.2597110

[44] Chenxiong Qian, Hyungjoon Koo, ChangSeok Oh, Taesoo Kim, and Wenke Lee. 2020. Slimium: Debloating the Chromium Browser with Feature Subsetting. In *Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (Virtual Event, USA) (CCS '20)*. Association for Computing Machinery, New York, NY, USA, 461–476. https://doi.org/10.1145/3372297.3417866

[45] Stephen Romansky, Neil C. Borle, Shaiful Chowdhury, Abram Hindle, and Russ Greiner. 2017. Deep Green: Modelling Time-Series of Software Energy Consumption. In *2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)*. 273–283. https://doi.org/10.1109/ICSME.2017.79

[46] Cagri Sahin, Lori Pollock, and James Clause. 2014. How do Code Refactorings Affect Energy Usage?. In *Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (Torino, Italy) (ESEM '14)*. Association for Computing Machinery, New York, NY, USA, Article 36, 10 pages. https://doi.org/10.1145/2652524.2652538

[47] Simon Schubert, Dejan Kostic, Willy Zwaenepoel, and Kang G. Shin. 2012. Profiling Software for Energy Consumption. In *2012 IEEE International Conference on Green Computing and Communications*. 515–522. https://doi.org/10.1109/GreenCom.2012.86

[48] Hashim Sharif, Muhammad Abubakar, Ashish Gehani, and Fareed Zaffar. 2018. TRIMMER: Application Specialization for Code Debloating. In *Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering*

(Montpellier, France) (ASE '18). Association for Computing Machinery, New York, NY, USA, 329–339. https://doi.org/10.1145/3238147.3238160

[49] Shivkumar Shivaji, E. James Whitehead, Ram Akella, and Sunghun Kim. 2013. Reducing Features to Improve Code Change-Based Bug Prediction. *IEEE Transactions on Software Engineering* 39, 4 (2013), 552–569. https://doi.org/10.1109/TSE.2012.43

[50] Shivkumar Shivaji, E. James Whitehead, Ram Akella, and Sunghun Kim. 2009. Reducing Features to Improve Bug Prediction. In *2009 IEEE/ACM International Conference on Automated Software Engineering*. 600–604. https://doi.org/10.1109/ASE.2009.76

[51] Xhevahire Tërnava, Mathieu Acher, and Benoit Combemale. 2023. Specialization of Run-time Configuration Space at Compile-time: An Exploratory Study. In *Proceedings of the 38th ACM/SIGAPP Symposium on Applied Computing* (Tallinn, Estonia) (SAC '23). Association for Computing Machinery, New York, NY, USA, 1459–1468. https://doi.org/10.1145/3555776.3578613

[52] Xhevahire Tërnava, Romain Lefevre, Quentin Perez, Djamel Eddine Khel-ladi, Mathieu Acher, and Benoit Combemale. 2025. The replication package for this paper. https://archive.softwareheritage.org/browse/revision/85286751845d59e9d032ffc0b91b92b2220954df/. Software Heritage ID: swh:1:rev:85286751845d59e9d032ffc0b91b92b2220954df.

[53] Roberto Verdecchia, Luis Cruz, June Sallou, Michelle Lin, James Wickenden, and Estelle Hotellier. 2022. Data-Centric Green AI An Exploratory Empirical Study. In *2022 International Conference on ICT for Sustainability (ICT4S)*. 35–45. https://doi.org/10.1109/ICT4S55073.2022.00015

[54] Denys Vlasenko and et. al. [n. d.]. BusyBox. https://busybox.net/

[55] Max Weber, Christian Kaltenecker, Florian Sattler, Sven Apel, and Norbert Siegmund. 2023. Twins or False Friends? A Study on Energy Consumption and Performance of Configurable Software. In *2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE)*. 2098–2110. https://doi.org/10.1109/ICSE48619.2023.00177

[56] Qi Xin, Myeongsoo Kim, Qirun Zhang, and Alessandro Orso. 2020. Program Debloating via Stochastic Optimization. In *Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: New Ideas and Emerging Results (Seoul, South Korea) (ICSE-NIER '20)*. Association for Computing Machinery, New York, NY, USA, 65–68. https://doi.org/10.1145/3377816.3381739

[57] Qi Xin, Qirun Zhang, and Alessandro Orso. 2023. Studying and Understanding the Tradeoffs Between Generality and Reduction in Software Debloating. In *Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering* (Rochester, MI, USA) (ASE '22). Association for Computing Machinery, New York, NY, USA, Article 99, 13 pages. https://doi.org/10.1145/3551349.3556970