💻 computer science

Watts This Smell: A Comprehensive Taxonomy of Software Energy Smells

Cet article introduit une taxonomie complète et indépendante du langage de 12 odeurs énergétiques logicielles et 65 causes profondes, laquelle est validée empiriquement par l'analyse de plus de 21 000 paires de codes Python pour démontrer que l'optimisation de l'énergie est distincte de l'optimisation des performances et pour fournir une ressource fondamentale pour le génie logiciel vert.

Auteurs originaux : Mohammadjavad Mehditabar, Saurabhsingh Rajput, Tushar Sharma

Publié 2026-07-09

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Mohammadjavad Mehditabar, Saurabhsingh Rajput, Tushar Sharma

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un chef dirigeant un immense restaurant ouvert 24 heures sur 24. Vous avez un menu de milliers de plats (des programmes logiciels) que vous servez à des millions de clients chaque jour.

Pendant longtemps, vous ne vous souciez que d'une seule chose : la Vitesse. « À quelle vitesse puis-je sortir ce plat de la cuisine ? » demandiez-vous. Si un plat mettait 10 secondes au lieu de 12, vous étiez satisfait.

Mais récemment, vous avez réalisé quelque chose d'effrayant : la vitesse n'est pas toute l'histoire. Parfois, un plat qui sort plus vite consomme en réalité une quantité massive d'électricité parce que le chef court frénétiquement dans tous les sens, allumant et éteignant le four, ou utilisant un énorme mixeur inefficace. C'est le problème que cet article traite. Il s'agit de trouver les « odeurs énergétiques » dans le code de votre cuisine — ces mauvaises habitudes qui gaspillent l'électricité même si la nourriture a bon goût.

Voici une décomposition simple de ce que les chercheurs ont fait :

1. Le gros problème : Vitesse vs Énergie

L'article commence par briser un mythe courant : « Plus rapide signifie toujours plus vert. »

L'analogie : Imaginez que vous conduisez une voiture. Vous pouvez faire le trajet jusqu'au magasin en 5 minutes en accélérant et en freinant brusquement (haute vitesse, haute consommation de carburant). Ou bien, vous pouvez faire le trajet en 7 minutes en roulant avec douceur (légèrement plus lent, mais beaucoup moins de carburant consommé).
La réalité : Dans le logiciel, écrire du code qui s'exécute rapidement ne signifie pas toujours économiser de l'énergie. Parfois, rendre le code plus rapide oblige en réalité le processeur de l'ordinateur à travailler plus dur et à consommer plus de puissance, gaspillant ainsi l'énergie globale.

2. La solution : Une taxonomie des « odeurs »

Les chercheurs voulaient créer un dictionnaire pour ces mauvaises habitudes. Ils les ont appelées des « odeurs énergétiques » (Energy Smells). Tout comme une mauvaise odeur dans une maison indique que quelque chose pourrit, une « odeur de code » indique à un développeur que quelque chose est inefficace.

Ils n'ont pas simplement deviné ; ils sont partis en une immense chasse au trésor :

La quête : Ils ont lu 60 articles scientifiques différents et examiné plus de 400 autres documents pour trouver toutes les manières dont le code gaspille l'énergie.
Le tri : Ils ont trouvé 320 mauvaises habitudes différentes. Ils les ont ensuite organisées en un arbre généalogique soigné à deux niveaux :
- Niveau 1 (La Catégorie) : Le type général d'odeur (ex: « Travail Gaspillé » ou « Mauvaise Utilisation de la Mémoire »).
- Niveau 2 (La Cause Racine) : La chose spécifique que vous avez mal faite (ex: « Vous avez calculé deux fois le même problème mathématique » ou « Vous avez gardé un objet lourd en mémoire alors que vous n'en aviez plus besoin »).

Le résultat : Ils ont créé une carte comprenant 12 catégories principales et 65 causes racines spécifiques. C'est la première fois qu'une carte aussi complète et indépendante du langage (fonctionnant pour Python, Java, C++, etc.) a été réalisée.

3. La preuve : Test dans le monde réel

Une liste est inutile si elle ne correspond pas à la réalité. Ainsi, les chercheurs ont construit une immense cuisine de test.

Le jeu de données : Ils ont pris 21 000 paires de code. Dans chaque paire, une version était la « mauvaise » façon et l'autre était la « bonne » façon, mais les deux faisaient exactement le même travail.
La mesure : Ils ont mesuré précisément la quantité d'électricité, de temps et de mémoire utilisée par chaque version.
Le détective IA : Ils ont utilisé une IA très intelligente (un LLM) pour examiner les 3 000 pires coupables et lui demander : « Laquelle de nos 65 odeurs cause ce gaspillage ? »

Ce qu'ils ont découvert :

L'IA avait raison : L'IA a réussi à associer le mauvais code à leur nouvelle carte dans 85 % des cas. Cela a prouvé que leur carte est réelle et utile.
Des odeurs multiples : La plupart des mauvais codes (71 %) n'étaient pas causés par une seule odeur, mais par un cocktail de plusieurs mauvaises habitudes simultanées.
Les grands gagnants : Les plus grandes économies d'énergie n'étaient pas toujours liées au code le plus rapide. Corriger les problèmes de mémoire (comme garder des données dont vous n'avez plus besoin) a permis d'économiser le plus d'énergie.
La surprise : Parfois, corriger un problème rendait le code plus lent mais économisait plus d'énergie. Cela prouve que vous ne pouvez pas vous contenter de regarder la vitesse ; vous devez regarder la facture d'électricité.

4. Pourquoi cela compte

Considérez ce papier comme donnant aux développeurs un voyant lumineux universel « Check Engine » pour l'énergie.

Avant, les développeurs pouvaient corriger un programme lent sans réaliser qu'ils gaspillaient en fait de l'électricité.
Désormais, ils disposent d'un vocabulaire commun. Si un développeur voit une odeur de « Calcul Redondant », il sait exactement quoi corriger pour économiser de l'énergie.

L'essentiel à retenir

Les chercheurs n'ont pas seulement trouvé quelques mauvaises habitudes ; ils ont construit une véritable encyclopédie du gaspillage énergétique dans les logiciels. Ils ont prouvé que pour sauver la planète (et l'argent), nous devons cesser de regarder uniquement la vitesse à laquelle le logiciel s'exécute et commencer à regarder l'efficacité avec laquelle il utilise l'énergie. Ils ont même rendu leurs données de « cuisine de test » et leur carte accessibles à tous, afin que le monde entier puisse commencer à cuisiner des logiciels plus verts.

Résumé Technique : Watts This Smell : Une Taxonomie Complète des Odeurs d'Énergie Logicielle

Problématique

Alors que le logiciel se propage dans tous les domaines, son empreinte énergétique globale est devenue une préoccupation environnementale critique. Si les « odeurs de code » (code smells) sont bien établies en tant qu'anti-patterns structurels dégradant la maintenabilité, une classe parallèle d'« odeurs d'énergie » existe : des implémentations de code source, des choix de conception ou des pratiques de programmation qui entraînent une utilisation inefficace des ressources matérielles et une consommation d'énergie inutile.

Une erreur conceptuelle importante en génie logiciel consiste à traiter la performance d'exécution et la consommation d'énergie comme des mesures interchangeables. Bien que corrélées, elles mesurent des phénomènes distincts. La performance reflète principalement le temps d'exécution ( $T$ ), tandis que la consommation d'énergie ( $E$ ) est le produit de la puissance appelée ( $P$ ) et du temps ( $E = P \times T$ ). Une exécution plus rapide ne garantit pas une consommation d'énergie plus faible ; un changement de code qui réduit le temps peut simultanément augmenter la puissance appelée, résultant en une consommation d'énergie totale plus élevée. De plus, les catalogues d'anti-patterns existants sont souvent spécifiques à un domaine (par exemple, uniquement Android), limités aux métriques de performance, manquent de classification fine des causes racines ou restent non validés par rapport à des données d'énergie mesurées. Il existe un besoin pour une taxonomie complète, indépendante du langage, qui comble le fossé entre l'identification des inefficacités et le refactoring actionnable.

Méthodologie

Les auteurs ont développé une taxonomie à deux niveaux via un processus rigoureux en plusieurs phases combinant une revue systématique de la littérature, le codage par la théorie ancrée (grounded theory) et une validation empirique.

1. Construction de la Taxonomie

Recherche Documentaire : Les auteurs ont mené une recherche systématique dans Scopus et ont effectué un estage de recherche par effet boule de neige (forward et backward snowballing) exhaustif. Ce processus a filtré plus de 400 travaux, en retenant finalement 60 études pertinentes (dont 15 issues de la recherche initiale et 45 du snowballing) ayant identifié des inefficacités de performance ou d'énergie au niveau du code.
Extraction de Données : À partir de ces études, 431 anti-patterns distincts ont été initialement identifiés.
Filtrage et Codage : Deux annotateurs indépendants ont appliqué des critères d'inclusion/exclusion pour filtrer les constructions indépendantes du langage, conservant 320 modèles pertinents. Ils ont ensuite appliqué un processus de codage par la théorie ancrée (codage ouvert, axial et sélectif) pour :
- Codage Ouvert : Isoler les causes racines fondamentales en supprimant le contexte spécifique à l'application.
- Codage Axial : Fusionner les codes redondants et scinder les mécanismes confondus.
- Codage Sélectif : Abstraire les codes raffinés en catégories de haut niveau basées sur leur impact global.
Finalisation : Par résolution collaborative, l'équipe a finalisé une taxonomie composée de 1-12 catégories primaires d'odeurs d'énergie et de 65 causes racines (sous-catégories).

2. Validation Empirique

Pour valider la taxonomie, les auteurs ont construit un ensemble de données étiquetées et appliqué un pipeline de classification automatisé :

Jeu de Données : Ils ont utilisé les partitions Python du jeu de données Pie-Perf (dérivé d'IBM CodeNet), filtrant 3age 857 instances pour arriver à 21 428 paires de code fonctionnellement équivalentes avec des métriques de temps et de mémoire vérifiées.
Profilage Énergétique : Ils ont mesuré empiriquement la consommation d'énergie pour ces paires en utilisant les outils Linux perf et time, capturant l'énergie du CPU/RAM et l'utilisation de la mémoire de pointe.
Sélection d'Échantillons : Les 3 000 paires présentant les différences d'énergie absolue les plus élevées ont été sélectionnées pour une analyse approfondie, représentant 98,4 % de la variance énergétique totale du jeu de données.
Classification par LLM : Un pipeline multi-étapes utilisant le modèle de raisonnement DeepSeek-V3.2 (685B) a classifié les 3 000 paires. Le pipeline opérait en trois étapes :
1. Analyse de la Cause Racine : Identification des inefficacités sans exposition préalable aux étiquettes de la taxonomie.
2. Triage de Catégorie : Cartographie des causes vers les catégories de haut niveau.
3. Classification de Sous-catégorie : Affinement en causes racines spécifiques.
Évaluation : Une vérité terrain annotée par l'humain a été établie sur un sous-ensemble aléatoire de 100 échantillons. Le pipeline a atteint une précision d'exactitude (exact-match) de 94 % et un score F1 micro de 0,97, confirmant l'applicabilité de la taxonomie au code réel.

Contributions Clés

Taxonomie Complète : Une taxonomie à deux niveaux, indépendante du langage, de 12 catégories d'odeurs d'énergie et de 65 causes racines. Les catégories s'étendent des effets matériels de bas niveau (ex: mauvaise localité matérielle) aux choix algorithmiques de haut niveau (ex: algorithmes sous-optimaux).
Jeu de Données Étiqueté : Un jeu de données accessible au public de 21 428 paires de code avec des mesures vérifiées d'énergie, de mémoire et de temps. Cela inclut un sous-ensemble de 3 000 paires annotées avec des classifications d'odeurs multi-labels et des traces de raisonnement étape par étape.
Analyse Empirique : Une analyse de la prévalence, de la cooccurrence et de l'impact énergétique de chaque catégorie d'odeur, fournissant la preuve que l'optimisation de l'énergie ne peut être réduite à la seule optimisation de la performance.

Résultats Clés

Prévalence : La taxonomie a réussi à mapper 84,6 % (55 sur 65) des causes racines aux 3 000 paires de code classées. Les catégories les plus prévalentes étaient l'Algorithmique Sous-optimale (C7, 41,6 %), l'Utilisation Inutile de la Mémoire (C6, 38,9 %) et les Modèles d'Itération Inefficaces (C3, 33,3 %).
Cooccurrence : 71 % des échantillons présentaient plusieurs odeurs cooccurrentes. Les cas multi-labels montraient un gaspillage d'énergie nettement plus élevé (économie médiane de 1 659 J) par rapport aux cas à label unique (549 J), indiquant que les inefficacités se cumulent.
Impact vs Fréquence : Il existe un désalignement entre la fréquence d'une odeur et son impact énergétique. Bien que les Algorithmes Sous-optimaux (C7) soient les plus courants, les odeurs liées à la mémoire (C5 et C6) ont généré les économies d'énergie médianes par correction les plus élevées (3 989 J et 3 670 J respectivement). Cela s'explique par le fait que les inefficacités de mémoire augmentent à la fois le temps d'exécution et la puissance appelée, tandis que les inefficacités algorithmiques affectent principalement le temps.
Variance de Puissance : La puissance appelée variait considérablement selon les patterns (60,5 W à 147,3 W). Dans 69,1 % des échantillons, le ratio d'énergie dépassait le ratio de temps, prouvant qu'une estimation naïve ( $E = \text{constante} \times T$ ) sous-estime systématiquement le gaspillage d'énergie.
Conception vs Implémentation : Les odeurs de conception (ex: choix de structure de données) ont produit des économies d'énergie médianes plus élevées (1 537 J) que les odeurs d'implémentation (1 146 J), soutenant l'idée que les corrections architecturales profondes produisent des gains plus importants.

Signification et Revendications

L'article pose qu'une taxonomie bien définie des odeurs d'énergie fournit un vocabulaire partagé et des directives de refactoring actionnables pour la communauté du génie logiciel. En distinguant l'efficacité énergétique de la simple optimisation de la performance, ce travail permet :

Le Génie Logiciel Vert (Green Software Engineering) : Les développeurs peuvent refactoriser le code pour améliorer l'efficacité énergétique parallèlement à la maintenabilité et à la performance.
Le Développement d'Outils : La taxonomie sert de fondation pour les outils d'analyse statique, les linters d'IDE et les garde-fous de CI/CD pour détecter et prévenir le gaspillage d'énergie.
L'Optimisation Pilotée par l'IA : Le jeu de données étiqueté et les traces de raisonnement peuvent entraîner des modèles d'IA générative pour synthétiser du code économe en énergie et effectuer un refactoring automatisé.

Les auteurs soulignent que leur taxonomie n'est pas un remplacement des anti-patterns de performance mais une extension nécessaire, car optimiser uniquement pour la vitesse ne garantit pas l'efficacité énergétique. Le travail vise à opérationnaliser la conscience énergétique dans les flux de développement logiciel standards, passant de la mesure du gaspillage à son élimination active.