EnCoDe: Energy Estimation of Source Code At Design-Time

Accurate energy measurement is the prerequisite for optimization. The most reliable method involves external hardware power meters, but their high cost and non-scalability limit their use to lab environments [13]. Consequently, the research community has shifted toward software-base power models. Intel's RAPL (Running Average Power Limit) has become the de facto standard for accessing on-chip energy counters [15]. However, as noted in recent studies, RAPL's update frequency (approx. 1ms) is often too coarse to capture the energy consumption of short-lived code constructs [11]. To address this granularity issue, tools like ALEA [20] and finer-grained profilers for embedded systems has been proposed. These approaches often use probabilistic sampling or instruction-level characterization to attribute energy to specific code regions.

To move energy assessment earlier in the lifecycle, researchers have explored static analysis and machine learning. In the mobile domain, approaches like MLEE[4] and EcoAndroid [29], have successfully demonstrated that structural metrics can predict energy consumption for Android applications. Similarly, FlipFlop [25] utilizes static analysis to optimize GPU kernel configurations for AI workloads.

For general-purpose languages like Python, tools such as GreenPy [28] provide application-level energy insights. However, these existing approaches typically operate at the level of entire applications, methods, or specific API calls. They lack the resolution to estimate the energy cost of fundamental control flow blocks (e.g., individual for loops or if conditions) in general-purpose context. Furthermore, many existing models can rely on deep learning, which can itself be energy-intensive. By contrast, EnCoDe targets this specific granularity gap using lightweight, interpretable models compliant with Green AI principles.

The first phase of our methodology, as shown in Figure 2, transforms a raw program text into a structured, analyzable computational block. This is achieved by first parsing the source code $\mathcal {P}$ to its Abstract Syntax Tree (AST), a hierarchical representation of the code's structure[1, 33], as shown in Figure 3. We then traverse the AST to identify node types that represent the root of distinct blocks. We define these block-rooting node types as:

Each node of these types, along with the entire subtree rooted at that node, is designated as a distinct block, as shown in Figure 3.

For Listing 1, this yields three nested blocks: B1 (FunctionDef calculate_score), B2 (For loop), and B3 (If statement inside B2), preserving their containment hierarchy.

The output of this phase is a collection of AST subtrees, each treated as an atomic block. Crucially, their hierarchical context is preserved (e.g., we know B3 is nested within B2), which is essential for all subsequent measurement and feature extraction.

With the code blocks identified, PowerLens measures their energy consumption to create our ground-truth dataset. This is the core technical challenge of our work: a block like the if statement (B3) as mentioned in our phase 1, executes in microseconds, far too fast for standard hardware counters like Intel's RAPL to measure directly [11]. Existing tools, therefore, cannot provide this data, as discussed in related work. PowerLens addresses this fundamental measurement problem by extending prior work [11], operating through four coordinated mechanisms.

4.2.2 Execution Amplification. A single execution of a block like our if statement (B3) is too fast to register on RAPL's millisecond-scale counters. To make this imperceptible signal measurable, PowerLens wraps the target block in a tight loop and executes it N times. This amplifies the total energy consumed to a level that rises clearly above the millisecond-scale. The total energy E_total, is calculated by taking two snapshots of the RAPL energy counter:(E_s) taken before the execution window, and (E_e) taken immediately after, as shown in Figure 4. The measured difference is modeled as:

where E_b is the true energy of a single execution and ϵ_N is the measurement noise which becomes negligible when averaged over N repetitions. By linear aggregation, the estimated mean energy per execution, $ \hat{E(b)}$, becomes:

For example, to measure B3 as discussed in Phase 1, we execute it N times. If the total measured energy E_total is 0.04 Joules (J), our initial measurement for a single execution is $ \hat{E}(B3) = 0.04 J / 1000 = 4.0 * 10^{-5} J$.

4.2.3 Synchronization - Aligning Execution and Sampling. Amplification alone is insufficient. If the execution loop starts or end in the middle of a RAPL sampling window, the measurement will be corrupted by energy from unrelated computations, as illustrated by the “unwanted” energy in Figure 4. To solve this, PowerLens synchronizes the start of the execution loop with the RAPL counter's refresh cycle. The start time t₀ is formally defined as the first moment a counter update is detected after the previous measurement start t_s :

where M_i is the cumulative RAPL reading time at time tick i. This precise alignment guarantees that the captured energy is attributable only to our target block.

4.2.4 Calibrated Subtraction. As amplified execution rarely finishes exactly on a RAPL boundary, a small “padding” interval is needed to complete the measurement window, and this padding consumes energy that must be removed. PowerLens subtracts a pre-calibrated energy cost for this padding, E_pad(δt), which is modeled as a linear function of the padding duration δt. The final, net energy for a single trial is then:

4.2.5 Statistical Aggregation - Achieving Reproducibility. To ensure the final value is robust against any residual system noise (eg., transient interrupts, SMM), the entire process is repeated m(= 10) times. Outliers are filtered from these trials using the standard Inter-quartile Range (IQR) rule [34]. The final energy signature for a block, $ \hat{E(b)}$, is the mean of the stable, non-outlier observations:

where Ω(b) denotes the non-outlier trial set.

This is applied independently to each block, producing reliable, ground-truth energy values: {B1: 7.7e − 2J, B2: 7.5e − 2J, B3: 1.4e − 6J}. This data, which could not be obtained with prior software methods forms our ground truth.

After energy measurements, the next step is to create a numerical "fingerprint" for each block based on its source code[27]. The goal is to compute a set of static features that capture the block's structural and syntactic characteristics, which we hypothesize are predictive of its energy consumption. This process creates the foundation for our predictive models, as illustrated in Figure 2.

With the finalized EnCoDe dataset, the objective of this phase is to train predictive models that can learn the relationships between a block's static features and its measured energy consumption. We frame this as a supervised learning problem, training two complementary models:

Regression Model (M_r): This model learns to predict the continuous energy value (in Joules). This allows to precisely compare the expected energy cost of different implementations.

Classification Model (M_c): This model provides more intuitive classification into energy tiers. The ground-truth energy values are discretized into three tiers ("Low," "Medium," "High") using equal frequency binning. This provides "lint-like" warning to quickly draw attention to potential energy hotspots. The classifier's architecture is agnostic to threshold placement, practitioners can re-bin the training data to match their energy budget constraints without retraining the feature extraction pipeline.

To ensure robustness and prevent bias from the skewed energy distribution, models are trained using stratified k-fold cross-validation and checked for overfitting.

For our example: The data points for our three blocks: (x_B1, 7.7e − 2J), (x_B2, 7.5e − 2J), and (x_B3, 1.4e − 6J), are fed into the training process. The models learn, for instance, that feature vectors with HasLoop = 1 and high OperatorDensity (like x_B2) tend to have higher energy values, while simple conditional blocks (like x_B3) have very low energy.

The Knowledge Base is the conceptual component in our methodology that stores analytical artifacts, decoupling resource-intensive training from real-time inference.

The trained models and the full dataset are stored in the Knowledge Base (Fig. 2), which holds the EnCoDe Dataset (D_EnCoDe) and a Model Registry containing M_r and M_c, decoupling resource-intensive training from real-time inference.

For our example: The data point (x_B3, 1.4e − 6J) for our if statement, along with the data for B1 and B2, is stored in the dataset. The trained models, M_r and M_c, which have learned from these and thousands of other examples, are stored in the registry.

The purpose of this phase is to provide crucial interpretability of the prediction models.

To achieve this, we perform a dual analysis that cross-validates our findings: one perspective is derived from the trained model's behavior, and the other from direct statistical evidence in the data.

Model-Based Feature Importance: First, we analyze the trained models to rank features based on how much they contribute to prediction accuracy. For tree-based ensembles, a feature's influence I(f_j) can be quantified as its average marginal reduction in prediction error across all decision trees in the model :

For our example: This dual analysis provides deep insights.

For the for loop (B2), the feature importance might rank the binary feature HasLoop = 1 and the CyclomaticComplexity metric very highly.

Simultaneously, the data-level analysis would likely show a strong positive Spearman correlation (ρ_s) between these same features and energy across the entire dataset.

This convergence gives us high confidence that the model has correctly learned a fundamental truth: loops and complex logic are significant drivers of energy consumption. The profiler's output is a unified ranking of these influential features, bridging the gap between prediction and explanation.

This phase operationalizes EnCoDe's goal of design-time energy estimation by translating static code blocks into predictions using pre-trained models.

The inference engine takes a newly written or modified code block as input and performs the following steps, as in Figure 2 :

Block Identification and Feature Extraction: The unseen code is parsed into its AST, and its constituent blocks are identified using the same mechanism as in Phase 1. The Feature Extractor from Phase 2 is then reused to compute the corresponding feature vector, $x_b^{new}$, for each new block.

Model-Based Prediction: The pre-trained regression (M_r) and classification (M_c) models are retrieved from the Model Registry in the Knowledge Base by the inference engine to generate the predictions.

Formally, the inference process can be represented as a transformation function Φ that maps the new block b_new and the stored models to an energy estimate and a tier :

For our example: Imagine a developer is refactoring our Listing 1 function and replaces the for loop (B2) with a while loop. As they finish writing the new while loop block, energy is inferred again. The regression model M_r might predict an energy value of $\hat{E}_b = 6.9e-2 J$. Simultaneously, the classification model M_c might predict the tier T_b = "Medium".

Our first research question examines whether energy consumption of microsecond-scale code blocks can be measured accurately and reproducibly. Each block was measured ten times, and across the dataset more than 90% of the blocks exhibited less than 10% variation between repeated trials after IQR outlier removal, indicating strong measurement stability and effective suppression of environmental noise. The results demonstrate that the proposed measurement infrastructure provides stable and reliable energy values at block granularity. This is a result of system stabilization and calibrated padding loops.

The measurement protocol also achieves both high sensitivity and broad coverage. The observed energy values spans six orders of magnitude, ranging from 2.37 × 10^{− 5} joules for trivial blocks to 7.48 × 10² joules for complex functions. This wide dynamic range confirms that the methodology is capable of capturing energy signatures of extremely short-lived constructs while remaining reliable. Without the amplification and synchronization mechanisms, many of these fine-grained blocks would register highly unstable or zero readings using conventional software-profilers.

Figure 5 illustrates block-level energy measurements for the score_function.py example, where annotated values indicate per-block energy consumption in joules as measured by PowerLens in Nested Blocks. Figure 6 compares the sum of block-level energy measurements obtained with PowerLens against coarse-grained measurements from PyRAPL⁴, grouped by construct type. To validate the correctness of the fine-grained measurements, we compared the aggregate energy obtained by summing block-level measurements from PowerLens with the total program-level energy reported by PyRAPL for the same codes, across 40 instances of each block type (see Figure 6). For all block categories, the aggregated PowerLens measurements closely match the corresponding coarse-grained energy reported by PyRAPL. In addition, PowerLens exhibits substantially lower variance across repeated measurements, as it stabilizes the execution environment and applies calibration loops to isolate block execution energy.

We next examine whether code metrics of source code provide meaningful explanatory signals for energy consumption and the nature of these signals.

We present the top 20 features from the correlation analysis, ranked by absolute correlation values (Pearson, Spearman, and Kendall) and feature importance scores (Extra Trees, Random Forest, and Gradient Boosting), in Table 1.

The feature importance results in Table 1 indicate that energy consumption does not strongly depend on any single feature. While several metrics exhibit statistically meaningful correlations with energy, most Pearson correlation coefficients are moderate in magnitude. In contrast, Spearman and Kendall coefficients are substantially higher for many features, suggesting that the relation between code features and energy consumption is largely non-linear.

Features such as operator_density, operator_entropy, and loops_count demonstrate linear associations and consistent predictive power across models. Notably, operator_density ranks first in all three models. Other features, including call_density, conditionals_count, literal_density, and unique_node_types, exhibit non-linear relationships with energy while maintaining stable predictive importance across models. The convergence of correlation analysis and predictive performance suggests that the models capture genuine underlying relationships. Although some features achieve high rank-based correlations primarily because they act as categorical indicators, functions_count exhibits high Spearman and Kendall coefficients but contributes little to prediction. Such features carry block specific knowledge and hence, effectively distinguish block types but can't predict energy consumption.

We assess prediction accuracy of static features on unseen code blocks and identify effective modeling choices.

As shown in Table  2, ensemble and tree-based regression models achieve strong predictive performance, with the XGBoost regressor attaining the highest test performance (R² of 0.755). SVR and Gradient Boosting follow closely, exhibiting similarly high accuracy and stable cross-validation results. These models outperform linear models, which struggle to capture the complex feature interactions present in the data. The energy distribution in our dataset is highly skewed, spanning several orders of magnitude. To mitigate this skewness and stabilize learning, we apply square root and logarithm transformations to the target values. These transformations significantly improves model convergence and generalization.

In addition to absolute error metrics, we evaluate relative prediction quality using MAPE. While absolute errors remain small, they are less informative given that the dataset spans several orders of magnitude. MAPE is therefore more appropriate; however, it overstates relative error for extremely low-energy blocks, where even minor absolute deviations result in large relative differences. Among the evaluated models, Random Forest and KNN achieve the lowest MAPE values, whereas Gradient Boosting and XGBoost exhibit higher MAPE values exceeding 1.7. This behavior reflects the intrinsic difficulty of accurately modeling micro-scale energy values and highlights the importance of reporting both absolute and relative error when evaluating fine-grained energy predictors.

The superior performance of ensemble and tree-based models is directly explained by the findings of RQ2. Since energy behavior arises from non-linear interactions among multiple code features, models capable of learning hierarchical decision boundaries and feature compositions are fundamentally better suited for this task. Tree ensembles naturally capture such interactions through recursive partitioning, whereas linear models cannot express these relationships without extensive manual feature engineering. While ensemble models deliver the highest accuracy, they also need higher modeling energy for inference. This requires a practical energy–accuracy tradeoff: the most accurate predictors might consume more energy themselves. However, this overhead remains negligible compared to the energy savings enabled by design-time optimization. Some models might offer minimal gains in accuracy with huge difference in energy consumption (for e.g. Gradient Boosting over XGBoost) and since the estimation is only supposed to be a guiding direction to identify hotspots, modeling energy to accuracy tradeoff is considerable.

Beyond regression, we evaluate the ability of models to categorize code blocks into energy tiers (low, medium, high) in Table  3. The XGBoost classifier achieves the best performance, with 80.6% accuracy and very stable cross-validation results. These classification results demonstrate that static features support reliable qualitative assessment of energy behavior, which is particularly valuable for developer-facing tools where actionable guidance matters.

To assess the contribution of each feature category, we conducted a systematic ablation (Table 4) using XGBoost under two complementary settings: (a) leave-one-group-out, removing each of the groups individually, and (b) single-group-only, training on each group in isolation. No single removal causes a dramatic performance collapse, confirming that feature groups contribute complementary signals (Table 4). The largest drops occur without Density (− 2.8 pp) and Counts (− 2.6 pp). Counts achieves the highest standalone performance (R² = 0.720, Acc $= 74.2\%$), yet no individual group approaches full-model performance (Table 4). Most notably, Complexity metrics alone yield R² = 0.067 and $51.2\%$ accuracy barely above random directly confirming that conventional complexity proxies are insufficient energy predictors.

Energy can now be treated as a metric of code Quality. Several long-standing challenges identified in prior survey and vision work on energy-aware software engineering can be addressed through fine-grained, design-time energy guidance [17]. The results for RQ1 and RQ3 demonstrate that energy consumption can be measured and estimated meaningfully at the level of small code blocks; this granularity aligns with how developers reason about and refactor code. In doing so, our methodology directly responds to earlier calls for improving energy observability beyond application and method-level measurements[11, 20]. PowerLens reduces reliance on external hardware power meters to obtain high-resolution measurements.

No single metric is a proxy for Energy. Contrary to approaches that treat some software-quality metrics (for example, size or cyclomatic complexity) as proxies for energy[36], our findings for RQ2 indicate that no single metric explains energy consumption to a large extent. Rather, energy behavior emerges from interactions among multiple code properties. The observed correlations and feature importance between block-level energy consumption and code metrics reinforce the view that energy is encoded in the compositional code features rather than isolated metrics. The results for RQ2 and RQ3 suggest that energy efficient ensemble models should be used to provide actionable energy guidance. These simple machine learning approaches provide approximate, design-time estimates which can be sufficient to distinguish energy-efficient constructs from energy-intensive ones. This aligns with survey studies that emphasize the practical value of timely but approximate estimation over delayed precise measurements[17, 40].

From a practitioner's perspective, the key implication of this work is that energy efficiency can be considered meaningfully during code construction rather than relegated to late-stage profiling. EnCoDe's primary goal is relative hotspot ranking within a codebase, not absolute Joule-level accuracy. The classifier flags blocks predicted as High energy tier with a lint-like warning. The developer examines the flagged block and considers alternative implementations. The regression model provides a comparative estimate between the original and refactored version to guide the choice. This workflow mirrors how developers already use static analyzers [21]. Energy-tier classification evaluated in RQ3 further lowers the barrier to adoption. The system surfaces lint-like information that points to constructs likely to be energy-intensive. This mirrors successful adoption patterns for other static analyzers and suggests energy concerns can be integrated into routine development practices. Embedding energy awareness in the development lifecycle also aligns with emerging SusDevOps perspectives, where sustainability considerations are addressed alongside performance, reliability, and maintainability [8, 26]. Our empirical results provide initial evidence that such integration is feasible in practice.

For researchers, this work demonstrates how open challenges in energy-aware software engineering can be addressed via an integrated empirical and static approach [17, 39, 40]. By coupling fine-grained runtime measurements with static code features, our methodology operationalizes calls to combine runtime energy data and design-time artifacts across the software lifecycle. This combined methodology enables several promising research directions: large-scale mining studies across languages and ecosystems, comparative analyzes of energy behavior across programming paradigms and systematic investigations into energy-aware refactoring.

Beyond methodological advances, our findings lend empirical support to treating energy consumption as a first-class software quality attribute. Prior work has argued conceptually for elevating energy alongside traditional qualities such as performance and maintainability; our fine-grained evidence helps close the gap by showing how energy can be measured, modeled, and reasoned about at the level of individual constructs. Finally, the availability of empirically grounded, block-level datasets opens opportunities to study energy behavior in emerging domains, such as AI-intensive systems and other compute-heavy applications, where understanding fine-grained energy signatures is increasingly critical.