Pith. sign in

REVIEW 3 major objections 7 minor 46 references

Static code metrics can't predict Java energy; runtime can, partially

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · glm-5.2

2026-07-08 15:48 UTC pith:W4ECPG3A

load-bearing objection Honest negative result on static metrics for Java method-level energy, but the positive finding (R²=0.46 with execution time) is vulnerable to selection bias from filtering zero-energy methods. the 3 major comments →

arxiv 2607.06124 v1 pith:W4ECPG3A submitted 2026-07-07 cs.SE cs.AIcs.LG

Static Metrics Are Insufficient: Predicting Java Method Energy Usage with Execution Time

Muhammad Imran , Vincenzo Stoico , Ivano Malavolta This is my paper
classification cs.SE cs.AIcs.LG
keywords energyexecutiontimejavastaticusagemetricscode
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper asks a practical question: can you predict how much energy a Java method will consume just by looking at its source code? The authors profile 2,786 Java methods from benchmark repositories, extract 33 static features (loop counts, cyclomatic complexity, library usage, etc.), and train eleven regression models to predict energy consumption measured in joules. The answer is essentially no. Static features alone produce R² values near zero across all models, meaning source code structure explains almost none of the variance in method-level energy. The paper then adds a single dynamic input — execution time in milliseconds — and R² rises to 0.46, still modest but a qualitative jump. The central mechanism the paper identifies is that method-level energy in Java is dominated by runtime behavior (how long a method runs, how often it is called, what the JVM does with it) rather than by the textual structure of the code. Feature selection and hyperparameter tuning yield marginal gains over defaults, suggesting the bottleneck is input information, not model sophistication. The authors position this as a boundary on what static analysis can achieve for energy reasoning: you cannot look at code and know its energy cost without some runtime measurement.

Core claim

The paper's central finding is a null result with a positive complement. Static source code metrics — 33 features spanning control flow, complexity, API usage, and method metadata — carry essentially no predictive signal for method-level energy consumption in Java (R²≈0 across eleven regression models). When execution time is added as a single lightweight dynamic feature, R² rises to 0.46, a substantial but still incomplete improvement. This gap isolates the mechanism: energy at method granularity is determined by runtime factors — execution duration, JVM behavior, invocation context — that are invisible to static analysis. Among static features, internal method calls and cyclomatic complex.

What carries the argument

The experimental pipeline pairs JoularJX (a JVM agent that attributes RAPL-based CPU/DRAM energy readings to individual methods via sampling at 1ms intervals) with async-profiler (which samples method-level execution time via CPU events). The intersection of methods covered by both profilers, after filtering zero-energy and incomplete records, yields 265 training instances from an initial pool of 2,786. Eleven regression models are evaluated across seven feature-selection configurations and subsequent hyperparameter tuning, with Random Forest consistently performing best.

Load-bearing premise

The paper's findings depend on JoularJX correctly attributing energy to individual methods. JoularJX samples at 1ms intervals using RAPL CPU/DRAM domains, and the paper itself cites evidence that short-lived or infrequently called methods produce noisy or zero readings under this configuration. After filtering, only 265 of the original 2,786 methods remain with complete data. If the profiler's attribution is systematically biased for this surviving subset, the R² values and (

What would settle it

If a subsequent study using a different energy attribution method (e.g., hardware performance counters with finer granularity, or differential measurement comparing method-present vs. method-absent executions) found that static features alone yielded substantially higher R², the central null result would be undermined. Alternatively, if the 265 surviving methods are shown to be a non-representative subset (e.g., only long-running, CPU-bound methods), the finding that static features are uninformative might not generalize.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Energy-aware refactoring tools that rely solely on static analysis will produce unreliable guidance at the method level; they need at least lightweight runtime profiling to be useful.
  • The gap between static predictability and runtime-determined energy suggests that JVM-level mechanisms (JIT compilation, garbage collection, class loading) carry energy signal that no source-level feature can capture, pointing toward JVM instrumentation as a necessary complement.
  • The R² ceiling of 0.46 even with execution time implies that remaining variance is driven by factors not measured here — CPU utilization, cache behavior, memory allocation patterns — which could be the next features to test.
  • The contrast with prior work showing R²=0.75 for isolated Python code blocks suggests that execution context (full-program vs. isolated-block profiling) is a major determinant of how predictable energy is from code features.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 7 minor

Summary. This paper investigates whether static source code metrics (33 features extracted via srcML) can predict method-level energy consumption in Java, and whether adding execution time as a lightweight dynamic feature improves prediction. The authors profile 2,786 Java methods from Rosetta Code and CLBG using JoularJX (energy) and async-profiler (execution time), apply filtering to obtain 265 methods with complete data, and train eleven regression models with 5-fold cross-validation. The central finding is that static features alone yield R²≈0, while adding execution time raises R² to 0.46. The paper includes a public replication package, feature importance analysis via SHAP, and a structured comparison across feature selection and hyperparameter tuning configurations.

Significance. The paper addresses a genuine gap: systematic, method-level energy prediction for Java using static features has limited prior work, and the negative result (static features alone are uninformative) is a useful empirical contribution. The inclusion of a public replication package, SHAP-based feature importance analysis, and a structured comparison of eleven models across seven feature-selection configurations are commendable. The comparison to Goyal et al.'s EnCoDe (R²=0.75 on isolated Python blocks) provides useful context for why method-level energy in full-program execution is harder to predict. The falsifiable claim that execution time dominates static features is testable and the replication package allows verification.

major comments (3)
  1. §3.3, Data Pre-processing: The filtering pipeline goes from 2,786 methods to 902 (profiler intersection) to 265 (after removing zero-energy methods). The paper justifies removing zero-energy methods as excluding 'trivial code paths that would distort training.' However, as the paper itself acknowledges in §5.1 (Construct Validity), JoularJX's 1ms sampling interval means that 'zero energy' often reflects methods that executed too briefly or infrequently to be captured by the sampler, not methods that consumed no energy. This creates a selection-on-outcome problem: the 265 surviving methods are systematically those where execution time and energy are both large enough to register at 1ms resolution. Since execution time is simultaneously the strongest predictor (§4.2, Figure 4a) and a determinant of whether a method survives filtering, the R²=0.46 attributed to execution time may be partly,
  2. §4.1, Figure 2 / §4.2, Table 3: The paper reports R²=0.454 for RF with all features (baseline) and R²=0.463 for RF with Variance Threshold (Table 3), then R²=0.462 after tuning (Table 4). These differences (0.454 vs. 0.463 vs. 0.462) are within the range of fold-level variance reported in §4.3 (fold R² ranges from 0.224 to 0.567). The paper does not report confidence intervals, standard deviations across folds, or any statistical test to assess whether the feature selection and tuning improvements are distinguishable from noise. Given n=265 and 5-fold CV, the per-fold validation set is ~53 methods, making R² estimates quite noisy. The claim that feature selection provides 'slight improvements' (§4.2) and tuning delivers 'minimal gains' (§4.3) is likely correct, but the paper should either (a) report fold-level variance or confidence intervals to substantiate that these differences are or
  3. §4.2, Figure 5: The paper reports that removing execution time drops RF R² from 0.454 to 0.005. This is the strongest evidence for the paper's central claim. However, the paper does not report the corresponding R² values for other models without execution time, nor does it report the R² for execution time alone (without static features). Given that execution time and energy are physically related (energy = power × time), reporting the R² of a univariate model using only log(execution_time) would clarify how much of the 0.46 is simply the time-energy correlation versus any additional explanatory power from static features. This is important because the paper's title and framing emphasize that static metrics are 'insufficient,' but the ablation in Figure 5 does not isolate whether static features add anything beyond execution time.
minor comments (7)
  1. §3.2: The paper states that execution times were recovered for 1,980 methods and energy values for 1,103 methods, but the intersection yields 902. It would help to clarify how many methods had energy but not execution time, and vice versa, to assess whether the intersection introduces bias beyond what is already discussed.
  2. §4.1: The paper reports MAPE values 'mostly below 2%' alongside R² values near 0.45. MAPE can be misleading when the target variable has values near zero (which log-transformed energy may approach). The paper should note this limitation or report MAPE on the original (untransformed) scale for interpretability.
  3. §3.3: The log transformation is applied to energy and execution time, but the paper does not specify whether the R² values are computed on the log-transformed or original scale. This should be clarified, as R² on log-transformed values is not directly comparable to R² on original values.
  4. Table 1: The feature 'methodScope' is listed as 'access specifier of the method' but is described as categorical and one-hot encoded in §3.3. The table should note this.
  5. §2: The related work mentions EnCoDe's ablation showing complexity metrics alone yield R²=0.067, which is consistent with this paper's near-zero R² for static features. This parallel is noted in §5 but could be foregrounded in §2 to strengthen the positioning.
  6. Figures 2, 3, 5: The axis labels and tick marks are rendered as glyph codes (e.g., '/uni00000035/uni00000029...') in the PDF, making them unreadable. This is likely a font embedding issue but should be fixed for the final version.
  7. §5.1, Construct Validity: The paper cites ref [8] (Brunnert, 2025) indicating that ~10ms sampling provides a better tradeoff than 1ms. Since the paper uses 1ms, it would be worth briefly explaining why 1ms was chosen despite this evidence, or acknowledging it as a potential source of measurement noise.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for a careful and constructive review. All three major comments are well-taken. Comment 1 identifies a genuine selection-on-outcome concern in our filtering pipeline; we will add an analysis including zero-energy methods and discuss the bias explicitly. Comment 2 correctly notes that we lack fold-level variance reporting; we will add standard deviations and confidence intervals. Comment 3 asks for a univariate execution-time baseline and per-model ablation; we will add both. We propose no standing objections.

read point-by-point responses

  1. Referee: §3.3, Data Pre-processing: The filtering pipeline creates a selection-on-outcome problem because execution time both determines survival and is the strongest predictor, potentially inflating R²=0.46.

    Authors: The referee correctly identifies a genuine methodological concern. The selection-on-outcome problem is real: methods surviving our filtering are systematically those where execution time and energy are large enough to register at JoularJX's 1ms resolution, and execution time is simultaneously our strongest predictor. We agree that this could inflate the R² attributed to execution time. In the revision, we will address this in three ways. First, we will re-run our pipeline including the zero-energy methods (labeling them with a small epsilon value or treating them as a separate classification task) to assess how the predictive performance changes. Second, we will add an explicit discussion of this selection bias as a threat to construct validity, going beyond the current acknowledgment in §5.1. Third, we will report the distribution of execution times for excluded vs. included methods to quantify the severity of the selection effect. We acknowledge that we cannot fully eliminate this bias given JoularJX's measurement resolution constraints—it is a fundamental limitation of software-based energy profiling at this granularity. However, we believe the core finding (static features alone are uninformative) is robust to this bias, since the selection effect would, if anything, make static features appear more predictive by restricting the range to methods where code structure matters more, yet static features still yield R²≈0. revision: yes

  2. Referee: §4.1/§4.2: R² differences across configurations (0.454 vs. 0.463 vs. 0.462) are within fold-level variance; no confidence intervals, standard deviations, or statistical tests are reported.

    Authors: This is a fair and accurate criticism. The differences between configurations (0.454 vs. 0.463 vs. 0.462) are indeed within the range of fold-level variance we already report (R² ranges from 0.224 to 0.567 across folds). With n=265 and per-fold validation sets of ~53 methods, these R² estimates are noisy, and we should not be presenting these small differences as meaningful without uncertainty quantification. In the revision, we will report fold-level standard deviations and 95% confidence intervals for all R² values in Tables 3 and 4. We will also add a Wilcoxon signed-rank test or paired t-test across folds for the top configurations to formally assess whether the feature selection and tuning improvements are distinguishable from noise. We expect the referee's assessment is correct—that these differences are not statistically significant—and we will adjust the language accordingly, reframing the feature selection and tuning results as 'no statistically significant improvement' rather than 'slight improvements.' The paper's core claims do not depend on these small differences; they depend on the large gap between static-only (R²≈0) and static+time (R²≈0.46), which is far outside fold-level variance. revision: yes

  3. Referee: §4.2, Figure 5: The ablation does not report R² for other models without execution time, nor R² for execution time alone. A univariate log(execution_time) model would clarify how much of R²=0.46 is simply the time-energy correlation.

    Authors: We agree completely. This is the most important analytical gap the referee identifies. Given that energy and execution time are physically related (energy = power × time), isolating the univariate predictive power of execution time is essential for interpreting our results. In the revision, we will add: (1) a univariate regression using only log(execution_time) as predictor, reporting R² for all eleven models (or at minimum for RF, the best performer); (2) the full ablation table showing R² without execution time for all models, not just RF; and (3) a direct comparison of execution-time-only R² vs. execution-time-plus-static-features R², so readers can see whether static features add any explanatory power beyond the physical time-energy correlation. We anticipate that execution time alone will explain a large fraction of the R²=0.46, and that static features add marginal incremental value. This actually strengthens our paper's central claim: if execution time alone captures most of the predictive power and static features add little on top, it reinforces the conclusion that static metrics are insufficient. We will revise the framing to make this explicit, noting that the R²=0.46 is largely driven by the physical energy-time relationship rather than by code structure. We will also discuss the implication that the remaining unexplained variance (~0.54) likely reflects factors not captured by either static features or execution time—such as varying power states, cache behavior, and JVM runtime mechanisms. revision: yes

Circularity Check

0 steps flagged

No significant circularity: standard empirical ML study with independent measurement of predictor and target

full rationale

This paper is a standard empirical machine-learning study with no first-principles derivation chain to audit for circularity. The central claim — that static features yield R²≈0 while adding execution time raises R² to 0.46 — is established through 5-fold cross-validation on held-out folds, not through any algebraic reduction. The strongest predictor (execution time, measured by async-profiler) and the target variable (energy, measured by JoularJX) are measured by different tools, so the prediction is not tautologically related to the target. No variable is defined in terms of another. The self-citations present ([25] replication package, [27] Experiment Runner, [23,24] prior performance-testing work, [34] teaching handbook, [46] Stoico et al. on Python energy) are methodological infrastructure, not load-bearing for the central finding. None invoke a uniqueness theorem, ansatz, or unverified premise that would force the conclusion. The skeptic's concern about selection bias from filtering zero-energy methods is a validity threat (correctness risk), not a circularity issue — the paper does not claim the filtering produces a prediction, and the concern is about potential bias in the dataset, not about the derivation reducing to its inputs. The study is self-contained against external benchmarks (CLBG, Rosetta Code) and uses standard, independently verifiable tools. Score 1 reflects the presence of minor self-citations that are not load-bearing.

Axiom & Free-Parameter Ledger

6 free parameters · 4 axioms · 0 invented entities

The paper introduces no new entities, particles, forces, or theoretical constructs. It is a purely empirical study. The free parameters are experimental design choices (repetition count, sampling interval, cool-down, fold count, k values, log transform) rather than fitted model constants. The key domain assumption is the validity of JoularJX's method-level energy attribution, which the paper's own threats-to-validity section partially undermines.

free parameters (6)
  • Repetition count (20) = 20
    Chosen to increase profiler coverage; not derived from a power analysis or optimization procedure. §3.2.
  • Sampling interval (1ms) = 1ms
    Set to match JoularJX's minimum resolution; the paper's own cited literature (ref [8]) suggests 10ms may be a better tradeoff. §3.2.
  • Cool-down period (30s) = 30s
    Selected as 'standard practice' without empirical justification for this specific value. §3.2.
  • k values for SelectKBest = {10, 20, 30}
    Chosen by hand for feature selection; not derived from data properties. §3.3.
  • Number of folds (5) = 5
    Chosen over 10-fold to ensure sufficiently large validation samples given n=265. §3.3.
  • Log transformation = ln
    Applied to mitigate skewness in energy and execution time distributions. §3.3.
axioms (4)
  • domain assumption JoularJX provides valid method-level energy attribution within the JVM
    The entire study depends on JoularJX's energy attribution being accurate. The paper cites evidence that it may be noisy at 1ms for short-lived methods. §3.2, §5.1.
  • domain assumption Rosetta Code and CLBG benchmark tasks are representative enough of Java method behavior to draw meaningful conclusions
    The authors acknowledge these are 'benchmark-style, self-contained, and primarily algorithmic' and do not represent large, event-driven, or framework-based systems. §3.1, §5.1.
  • ad hoc to paper Methods with zero energy consumption are trivial code paths that should be excluded
    The paper removes zero-energy methods as 'likely trivial code paths that would distort training' without verifying this assumption. §3.3.
  • standard math Standard regression metrics (R², MAE, MSE, MAPE) adequately capture predictive performance for this task
    The authors note these may not capture sensitivity to outliers but use them as the evaluation framework. §5.1.

pith-pipeline@v1.1.0-glm · 22177 in / 2917 out tokens · 417577 ms · 2026-07-08T15:48:36.078130+00:00 · methodology

0 comments
read the original abstract

The increasing energy demand of software systems is raising concerns about their environmental impact and associated costs. Reasoning on energy usage early in the development flow has the potential to significantly reduce the overall energy usage of a software system, as it allows developers to make informed design and refactoring decisions before inefficiencies propagate. However, assessing energy usage without repeated profiling and direct measurement is difficult, which limits early reasoning in practice. This study investigates the limits of method-level energy prediction in Java, examining whether static source code metrics complemented with method-level execution time can estimate the energy consumption of Java methods. We profile 2,786 Java methods to extract 33 static features and measure execution time and energy, then train and compare eleven regression models. Our findings show that static source code metrics alone yield poor predictive performance, with average R2 values close to zero. Incorporating execution time as a lightweight dynamic input significantly improves accuracy, raising R2 to as high as 0.46. Execution time, internal method calls, and cyclomatic complexity consistently emerge as the strongest predictors of energy consumption.

Figures

Figures reproduced from arXiv: 2607.06124 by Ivano Malavolta, Muhammad Imran, Vincenzo Stoico.

Figure 1
Figure 1. Figure 1: Overview of the study workflow and profiling setup. ther performed extensive model comparison, tuning, or feature selection analysis. Kruglov et al. [30] and Schuler et al. [43] also note the growing trend of model￾based estimation, yet few studies systematically compare the performance of different models or assess the impact of tuning and feature selection on predic￾tion accuracy. Our study addresses thi… view at source ↗
Figure 2
Figure 2. Figure 2: Baseline prediction performance. 4.2 RQ2: Feature selection We evaluated six feature preprocessing techniques against the baseline using all features [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Feature-selection performance. although method name length does not directly represent computation, it may act as a weak proxy for design or implementation style. Finally, we isolated the contribution of execution time by training the models without it [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Feature importance analysis for RQ2 [PITH_FULL_IMAGE:figures/full_fig_p010_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Effect of excluding execution time. 4.3 RQ3: Hyperparameter tuning We tuned RF and ADA as they are the only two models featured in the top five configurations in [PITH_FULL_IMAGE:figures/full_fig_p011_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Box plots comparing actual and predicted log-transformed energy consumption values across all five folds for the top-performing RF configuration. 5 Discussion Our findings show that method-level energy consumption in Java can be partially predicted by combining static code features with execution time, though predic￾tive performance remains modest with the best R2 below 0.47. RF emerged as the most consist… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

46 extracted references · 46 canonical work pages · 3 internal anchors

  1. [1]

    Astronomy and Computing10, 1–8 (2015)

    Akeret,J.,Gamper,L.,Amara,A.,Refregier,A.:Hope:Apythonjust-in-timecom- piler for astrophysical computations. Astronomy and Computing10, 1–8 (2015)

    work page 2015

  2. [2]

    Akinli Koçak, S.: Software energy consumption prediction using software code met- rics. Ph.D. thesis, Toronto Metropolitan University (2018)

    work page 2018

  3. [3]

    Sustainable Computing: Informatics and Systems32, 100594 (2021)

    Alvi, H.M., Majeed, H., Mujtaba, H., Beg, M.O.: Mlee: Method level energy es- timation—a machine learning approach. Sustainable Computing: Informatics and Systems32, 100594 (2021)

    work page 2021

  4. [4]

    Nature Astronomy 5(4) (2021)

    Augier,P.,Bolz-Tereick,C.F.,Guelton,S.,Mohanan,A.V.:Reducingtheecological impact of computing through education and python compilers. Nature Astronomy 5(4) (2021)

    work page 2021

  5. [5]

    In: 22nd international symposium on computer and information sci- ences

    Baskeles, B., Turhan, B., Bener, A.: Software effort estimation using machine learn- ing methods. In: 22nd international symposium on computer and information sci- ences. IEEE (2007)

    work page 2007

  6. [6]

    In: The art and science of analyzing software data, pp

    Bener, A., Misirli, A.T., Caglayan, B., Kocaguneli, E., Calikli, G.: Lessons learned from software analytics in practice. In: The art and science of analyzing software data, pp. 453–489. Elsevier (2015) Static Metrics Are Insufficient: Predicting Java Method Energy 15

    work page 2015

  7. [7]

    Journal of machine learning research13(2) (2012)

    Bergstra, J., Bengio, Y.: Random search for hyper-parameter optimization. Journal of machine learning research13(2) (2012)

    work page 2012

  8. [8]

    In: Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering (2025)

    Brunnert, A.: Evaluating the accuracy of software energy consumption models for java applications at process and transaction levels. In: Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering (2025)

    work page 2025

  9. [9]

    In: Proceedings of the 20th ACM SIGPLAN International Conference on Managed Programming Languages and Runtimes

    Burchell, H., Larose, O., Kaleba, S., Marr, S.: Don’t trust your profiler: An empiri- cal study on the precision and accuracy of java profilers. In: Proceedings of the 20th ACM SIGPLAN International Conference on Managed Programming Languages and Runtimes. pp. 100–113 (2023)

    work page 2023

  10. [10]

    Estimating the Energy Footprint of Software Systems: a Primer

    Castor, F.: Estimating the energy footprint of software systems: a primer. arXiv preprint arXiv:2407.11611 (2024)

    work page internal anchor Pith review Pith/arXiv arXiv 2024

  11. [11]

    In: 38th International Conference on Automated Software Engineering (ASE) (2023)

    Chattaraj, R., Chimalakonda, S.: Rjoules: An energy measurement tool for r. In: 38th International Conference on Automated Software Engineering (ASE) (2023)

    work page 2023

  12. [12]

    Chowdhury, S., Holmes, R., Zaidman, A., Kazman, R.: Revisiting the debate: Are code metrics useful for measuring maintenance effort? Empirical Software Engi- neering27(6), 158 (2022)

    work page 2022

  13. [13]

    In: SCAM 2011 (2011)

    Collard, M.L., Decker, M.J., Maletic, J.I.: Lightweight transformation and fact extraction with the srcml toolkit. In: SCAM 2011 (2011)

    work page 2011

  14. [14]

    In: Proceedings of the 3rd GREENS

    Corral, L., Georgiev, A.B., Sillitti, A., Succi, G.: Can execution time describe accurately the energy consumption of mobile apps? an experiment in android. In: Proceedings of the 3rd GREENS. pp. 31–37 (2014)

    work page 2014

  15. [15]

    In: QUATIC

    Cursaru, V.A., Duits, L., Milligan, J., Ural, D., Sanchez, B.R., Stoico, V., Mala- volta, I.: A controlled experiment on the energy efficiency of the source code gen- erated by code llama. In: QUATIC. Springer (2024)

    work page 2024

  16. [16]

    Journal of Open Source Software (2024)

    Fieni, G., Acero, D.R., Rust, P., Rouvoy, R.: Powerapi: A python framework for building software-defined power meters. Journal of Open Source Software (2024)

    work page 2024

  17. [17]

    good enough

    Ganesh, S., Palma, F., Olsson, T.: Are source code metrics “good enough” in pre- dicting security vulnerabilities? Data7(9), 127 (2022)

    work page 2022

  18. [18]

    ACM Computing Surveys (CSUR)52(4) (2019)

    Georgiou, S., Rizou, S., Spinellis, D.: Software development lifecycle for energy efficiency: techniques and tools. ACM Computing Surveys (CSUR)52(4) (2019)

    work page 2019

  19. [19]

    EnCoDe: Energy Estimation of Source Code At Design-Time

    Goyal, S., Matathammal, A., Vaidhyanathan, K.: Encode: Energy estimation of source code at design-time. arXiv preprint arXiv:2605.00504 (2026)

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  20. [20]

    In: Proceedings of the 18th International Workshop on Software and Compilers for Embedded Systems (2015)

    Grech, N., Georgiou, K., Pallister, J., Kerrison, S., Morse, J., Eder, K.: Static analysis of energy consumption for llvm ir programs. In: Proceedings of the 18th International Workshop on Software and Compilers for Embedded Systems (2015)

    work page 2015

  21. [21]

    Future Generation Computer Systems155, 402–418 (2024)

    Guldner, A., Bender, R., Calero, C., et al.: Development and evaluation of a refer- encemeasurementmodelforassessingtheresourceandenergyefficiencyofsoftware products and components: Green software measurement model (gsmm). Future Generation Computer Systems155, 402–418 (2024)

    work page 2024

  22. [22]

    Machine learning46(1), 389–422 (2002)

    Guyon, I., Weston, J., Barnhill, S., Vapnik, V.: Gene selection for cancer classifi- cation using support vector machines. Machine learning46(1), 389–422 (2002)

    work page 2002

  23. [23]

    In: Proceedings of the 28th EASE (2024)

    Imran, M., Cortellessa, V., Di Ruscio, D., Rubei, R., Traini, L.: An empirical study on code coverage of performance testing. In: Proceedings of the 28th EASE (2024)

    work page 2024

  24. [24]

    Empirical Software Engineering30(6), 157 (2025)

    Imran, M., Cortellessa, V., Di Ruscio, D., Rubei, R., Traini, L.: Is code coverage of performance tests related to source code features? an empirical study on open- source java systems. Empirical Software Engineering30(6), 157 (2025)

    work page 2025

  25. [25]

    Imran, M., Stoico, V., Malavolta, I.: Replication package for estimating energy usage, https://github.com/imran9pk/replication-package_method_energy_java

    work page

  26. [26]

    Jiarpakdee, J., Tantithamthavorn, C., Treude, C.: Autospearman: Automatically mitigating correlated software metrics for interpreting defect models (2018) 16 Muhammad Imran, Vincenzo Stoico, and Ivano Malavolta

    work page 2018

  27. [27]

    Science of Computer Programming252, 103415 (2026)

    Karsten, M., Calin Dragomir, A., Apsan, R., Stoico, V., Malavolta, I.: Exper- iment runner: A tool for the automatic orchestration of experiments target- ing software systems. Science of Computer Programming252, 103415 (2026). https://doi.org/10.1016/j.scico.2025.103415

    work page doi:10.1016/j.scico.2025.103415 2026

  28. [28]

    In: 2025 IEEE Conference on Software Testing, Verification and Validation (2025)

    Kifetew, F., Prandi, D., Susi, A.: On the energy consumption of test generation. In: 2025 IEEE Conference on Software Testing, Verification and Validation (2025)

    work page 2025

  29. [29]

    In: Proceedings of the 7th ACM/SPEC on International Conference on Performance Engineering

    von Kistowski, J., Block, H., Beckett, J., Spradling, C., Lange, K.D., Kounev, S.: Variations in cpu power consumption. In: Proceedings of the 7th ACM/SPEC on International Conference on Performance Engineering. pp. 147–158 (2016)

    work page 2016

  30. [30]

    Springer Nature (2023)

    Kruglov, A., Succi, G.: Developing sustainable and energy-efficient software sys- tems. Springer Nature (2023)

    work page 2023

  31. [31]

    In: Eighth International Green and Sustainable Computing Conference (IGSC) (2017)

    Kumar, M., Li, Y., Shi, W.: Energy consumption in java: An early experience. In: Eighth International Green and Sustainable Computing Conference (IGSC) (2017)

    work page 2017

  32. [32]

    Empirical Software Engineering26(6), 114 (2021)

    Laaber, C., Basmaci, M., Salza, P.: Predicting unstable software benchmarks using static source code features. Empirical Software Engineering26(6), 114 (2021)

    work page 2021

  33. [33]

    Quantifying the Carbon Emissions of Machine Learning

    Lacoste, A., Luccioni, A., Schmidt, V., Dandres, T.: Quantifying the carbon emis- sions of machine learning. arXiv preprint arXiv:1910.09700 (2019)

    work page internal anchor Pith review Pith/arXiv arXiv 1910

  34. [34]

    Ten Years of Teaching Empirical Software Engineering in the context of Energy-efficient Software

    Malavolta, I., Stoico, V., Lago, P.: Handbook on Teaching Empirical Software Engineering, chap. Ten Years of Teaching Empirical Software Engineering in the context of Energy-efficient Software. Springer Nature Switzerland (2024)

    work page 2024

  35. [35]

    Oxford Open Energy2, oiac011 (2023)

    Manner, J.: Black software—the energy unsustainability of software systems in the 21st century. Oxford Open Energy2, oiac011 (2023)

    work page 2023

  36. [36]

    In: 18th International Conference on Intelligent Environments (2022)

    Noureddine, A.: Powerjoular and joularjx: Multi-platform software power monitor- ing tools. In: 18th International Conference on Intelligent Environments (2022)

    work page 2022

  37. [37]

    In: ICSA

    Noureddine, A., Le Goaer, O.: Investigating the impact of software design patterns on energy consumption. In: ICSA. pp. 153–163. IEEE (2025)

    work page 2025

  38. [38]

    Oliveira, W., Oliveira, R., Castor, F., Pinto, G., Fernandes, J.P.: Improving energy- efficiencybyrecommendingjavacollections.EmpiricalSoftwareEngineering(2021)

    work page 2021

  39. [39]

    In: 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER)

    Oliveira, W., Torres, W., Castor, F., Ximenes, B.H.: Native or web? a preliminary study on the energy consumption of android development models. In: 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER). vol. 1, pp. 589–593. IEEE (2016)

    work page 2016

  40. [40]

    org/stable/modules/generated/sklearn.feature_selection.SelectKBest.html

    Pedregosa, F., Varoquaux: Scikit-learn: SelectKBest (2011), https://scikit-learn. org/stable/modules/generated/sklearn.feature_selection.SelectKBest.html

    work page 2011

  41. [41]

    Pereira, R., Couto, M., Ribeiro, F., Rua, R., Cunha, J., Fernandes, J.P., Saraiva, J.: Energy efficiency across programming languages: how do energy, time, and memory relate? In: Proceedings of the 10th ACM SLE. pp. 256–267 (2017)

    work page 2017

  42. [42]

    Journal of Systems and Software p

    Poy, O., Moraga, M.Á., García, F., Calero, C.: Impact on energy consumption of design patterns, code smells and refactoring techniques: A systematic mapping study. Journal of Systems and Software p. 112303 (2024)

    work page 2024

  43. [43]

    Sustainable Computing: Informatics and Systems41, 100919 (2024)

    Schuler, A., Kotsis, G.: A systematic review on techniques and approaches to es- timate mobile software energy consumption. Sustainable Computing: Informatics and Systems41, 100919 (2024)

    work page 2024

  44. [44]

    scikit-learn developers: scikit-learn documentation, https://scikit-learn.org/ stable/modules/generated/sklearn.feature_selection.VarianceThreshold.html

    work page

  45. [45]

    In: Proceedings of the 32nd ACM CC (2023)

    Shajii, A., Ramirez, G., Smajlović, H., Ray, J., Berger, B., Amarasinghe, S., Nu- managić, I.: Codon: A compiler for high-performance pythonic applications and dsls. In: Proceedings of the 32nd ACM CC (2023)

    work page 2023

  46. [46]

    In: Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering (2025)

    Stoico, V., Dragomir, A.C., Lago, P.: An empirical study on the performance and energy usage of compiled python code. In: Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering (2025)

    work page 2025