💻 computer science

Watts This Smell: A Comprehensive Taxonomy of Software Energy Smells

本文引入了一个包含 12 种软件能耗异味和 65 个根源的全面且与语言无关的分类法，并通过对超过 21,000 对 Python 代码的分析进行了实证验证，旨在证明能耗优化与性能优化是不同的，并为绿色软件工程提供基础资源。

原作者： Mohammadjavad Mehditabar, Saurabhsingh Rajput, Tushar Sharma

发布于 2026-07-09

📖 1 分钟阅读☕ 轻松阅读

原作者： Mohammadjavad Mehditabar, Saurabhsingh Rajput, Tushar Sharma

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你是一位经营着一家大型 24 小时餐厅的大厨。你的菜单上有成千上万道菜肴（软件程序），每天都要为数百万名顾客服务。

很长一段时间以来，你只关心一件事：速度。“这道菜出厨房要多久？”你会这样问。如果一道菜从 12 秒缩短到 10 秒，你会感到很欣慰。

但最近，你意识到了一些可怕的事实：速度并不是故事的全貌。 有时，一道出餐更快的菜实际上会消耗大量的电力，因为厨师在厨房里疯狂地来回奔跑，或者不停地开关烤箱，或者使用了一个巨大且低效的搅拌机。这就是这篇论文要解决的问题。它旨在寻找你厨房代码中的“能量异味”——那些即使食物味道没问题，却依然在浪费电力的坏习惯。

以下是研究人员所做工作的简单拆解：

1. 大问题：速度 vs. 能量

论文首先打破了一个常见的迷思：“更快总是意味着更环保。”

类比： 想象你在开车。你可以通过猛踩油门和频繁刹车在 5 分钟内到达商店（高速，高油耗）。或者，你可以通过平稳驾驶在 7 分钟内到达（速度稍慢，但油耗极低）。
现实： 在软件领域，编写运行速度快的代码并不总是能节省能量。有时，让代码运行得更快实际上会让计算机的处理器工作得更辛苦，从而消耗更多电力，造成整体能量的浪费。

2. 解决方案：“异味”分类法

研究人员想要为这些坏习惯建立一本字典。他们称之为**“能量异味”（Energy Smells）**。就像房子里的异味预示着有东西在腐烂一样，“代码异味”是在告诉开发者某些地方效率低下。

他们并非凭空猜测，而是进行了一场大规模的寻宝：

搜寻过程： 他们阅读了 60 篇不同的科学论文，并筛选了 400 多份其他文档，以找出每一种导致代码浪费能量的方式。
分类过程： 他们发现了 320 种不同的坏习惯。随后，他们将这些习惯整理成一个整齐的两级家族树：
- 第一层（类别）： 异味的总体类型（例如，“浪费工作”或“糟糕的内存使用”）。
- 第二层（根本原因）： 你具体做错的地方（例如，“你把同一个数学题计算了两遍”或“你在不需要时仍保留着沉重的内存对象”）。

结果： 他们创建了一张包含 12 个主要类别和 65 个特定根本原因的地图。这是首次制作出如此全面、且与语言无关（适用于 Python、Java、C++ 等）的地图。

3. 验证：在现实世界中测试

如果一份清单与现实不符，那它就是毫无用处的。因此，研究人员建立了一个巨大的“测试厨房”。

数据集： 他们提取了 21,000 对代码。在每一对中，一个版本是“糟糕”的方式，另一个版本是“优秀”的方式，但它们完成的工作完全相同。
测量： 他们精确测量了每个版本消耗的电力、时间和内存。
AI 侦探： 他们使用了一个超级智能的 AI（大语言模型/LLM）来观察表现最差的前 3,000 个案例，并询问：“我们的 65 种异味中，哪一种正在导致这种浪费？”

他们的发现：

AI 是正确的： AI 成功地将坏代码与他们的新地图匹配起来，准确率达到了 85%。这证明了他们的地图是真实且有用的。
多种异味并存： 大多数坏代码（71%）并非仅由一种异味引起，而是多种坏习惯同时发生的“鸡尾酒式”组合。
大赢家： 最大的节能点并不总是那些运行最快的代码。修复内存问题（例如，保留了不需要的数据）节省的能量最多。
令人意外的结果： 有时，修复一个问题会让代码运行得更慢，但却能节省更多的能量。这证明了你不能只看速度；你必须看电费单。

4. 为什么这很重要

你可以把这篇论文看作是给了开发者一个通用的**“发动机检查灯”**。

在以前，开发者可能会修复一个运行缓慢的程序，却没意识到他们实际上是在浪费电力。
现在，他们拥有了一套共同的语言。如果一名开发者看到了“冗余计算”这种异味，他们就会确切知道为了省电该去修复什么。

核心结论

研究人员不仅发现了几种坏习惯，还构建了一部完整的软件能量浪费百科全书。他们证明了，为了拯救地球（以及省钱），我们不能只盯着软件运行得有多快，而要开始关注它使用电力的效率有多高。他们甚至发布了他们的“测试厨房”数据和这张地图供所有人使用，以便全世界都能开始烹饪更绿色的软件。

技术摘要：Watts This Smell（这股味道是什么）：软件能耗“气味”的全面分类法

问题陈述

随着软件在各个领域的广泛应用，其总体的能量足迹已成为一个关键的环境问题。虽然“代码气味”（code smells）作为降低可维护性的结构性反模式已被广泛认可，但存在着一类平行的“能量气味”（energy smells）：即导致硬件资源使用效率低下和不必要能耗的源代码实现、设计选择或编程实践。

软件工程领域的一个重大误解是将执行性能与能耗视为可互换的指标。虽然两者相关，但它们衡量的是不同的现象。性能主要反映执行时间（ $T$ ），而能耗（ $E$ ）是功率（ $P$ ）与时间的乘积（ $E = P \times T$ ）。快速执行并不保证低能耗；一个减少执行时间的代码更改可能会同时增加功率消耗，从而导致更高的总能耗。此外，现有的反模式目录通常是特定领域的（例如仅限 Android），或者局限于性能指标，缺乏细粒度的根因分类，或者未经过实测能耗数据的验证。因此，需要一个能够弥合识别低效与可操作重构之间差距的、语言无关的全面分类法。

研究方法

作者通过结合系统文献综述、扎根理论编码和实证验证的多阶段严谨过程，开发了一个两层结构的分类法。

1. 分类法构建

文献检索： 作者在 Scopus 中进行了系统搜索，并执行了详尽的前向和后向滚雪球检索。该过程筛选了 400 多篇著作，最终保留了 60 篇相关的研究（包括初始搜索中的 15 篇和滚雪球中的 45 篇），这些研究识别出了代码层面的性能或能量低效问题。
数据提取： 从这些研究中，最初识别出 431 个不同的反模式。
过滤与编码： 两名独立标注员应用包含/排除标准来过滤语言无关的构造，保留了 320 个相关模式。随后，他们应用了扎根理论编码过程（开放式、轴心式和选择性编码）来进行：
- 开放式编码（Open Coding）： 通过剥离应用特定的上下文，分离出基本的根因。
- 轴心式编码（Axial Coding）： 合并冗余的代码并拆分混淆的机制。
- 选择式编码（Selective Coding）： 基于其总体影响将精炼后的代码抽象为高层类别。
定稿： 通过协作解决，团队最终确定了一个由 12 个主要能耗类别和 65 个根因（子类别）组成的分类法。

2. 实证验证

为了验证该分类法，作者构建了一个标记数据集，并应用了一个自动化分类流水线：

数据集： 他们利用了 Pie-Perf 数据集的 Python 部分（衍生自 IBM CodeNet），将 36,857 个实例过滤为 21,428 个具有经验证的时间和内存指标的功能等价代码对。
能耗剖析： 他们使用 Linux perf 和 time 工具对这些代码对进行了实证能耗测量，捕捉了 CPU/RAM 能耗和峰值内存使用情况。
样本选择： 他们选择了绝对能量差异最大的前 3,000 个代码对进行深度分析，这些代码对涵盖了数据集中 98.4% 的总能量方差。
LLM 分类： 使用 DeepSeek-V3.2 (685B) 推理模型的多步流水线对 3,000 个代码对进行了分类。该流水线分为三步运行：
1. 根因分析： 在没有预先接触分类标签的情况下识别低效原因。
2. 类别分选： 将原因映射到高层类别。
3. 子类别分类： 精炼为具体的根因。
评估： 在一个随机抽取的 100 个样本子集上建立了人工标注的地面真值（ground truth）。该流水线实现了 94% 的精确匹配准确率和 0.97 的 micro F1 分数，证实了该分类法对实际代码的适用性。

核心贡献

全面的分类法： 一个语言无关的两层分类法，包含 12 个能耗类别和 65 个根因。这些类别涵盖了从底层硬件效应（如糟糕的硬件局部性）到高层算法选择（如次优算法）的范围。
标记数据集： 一个公开可用的包含 21,428 个代码对的数据集，具有经过验证的能量、内存和时间测量值。其中包括一个经过人工验证的 3,000 个代码对子集，带有多标签能耗气味分类和逐步推理轨迹。
实证分析： 对每种气味类别的普遍性、共现性和能量影响进行了分析，为“能耗优化不能简单等同于性能优化”提供了证据。

关键结果

普遍性： 该分类法成功将 84.6% (55/65) 的根因为 3,000 个分类代码对进行了映射。最普遍的类别是次优算法（C7, 41.6%）、不必要的内存使用（C6, 38.9%）和低效迭代模式（C3, 33.3%）。
共现性： 71% 的样本表现出多种共现的气味。多标签案例显示的能量浪费显著高于单标签案例（中位节省量为 1,659 J 对比 549 J），表明低效会产生复合效应。
影响 vs. 频率： 气味的频率与其能量影响之间存在错位。虽然次优算法（C7）最为常见，但 内存相关的气味（C5 和 C6） 产生了最高的单次修复中位能量节省（分别为 3,989 J 和 3,670 J）。这是因为内存低效既增加了执行时间又增加了功率消耗，而算法低效主要影响时间。
功率方差： 功率消耗在不同模式间差异显著（60.5 W 至 147.3 W）。在 69.1% 的样本中，能量比例超过了时间比例，证明了朴素估计（ $E = \text{constant} \times T$ ）会系统性地低估能量浪费。
设计 vs. 实现： 设计层面的气味（如数据结构选择）产生的能量中位节省量（1,537 J）高于实现层面的气味（1,146 J），支持了“更深层的架构修复能带来更大收益”的观点。

意义与主张

本文认为，一个定义良好的能耗气味分类法为软件工程界提供了一个共同的词汇和可操作的重构指南。通过区分能效与单纯的性能优化，这项工作使以下方面成为可能：

绿色软件工程： 开发者可以在提高可维护性和性能的同时，通过重构代码来提高能效。
工具开发： 该分类法可作为静态分析工具、IDE 检查器和 CI/CD 防护机制的基础，用于检测和防止能量浪费。
AI 驱动的优化： 标记数据集和推理轨迹可以训练生成式 AI 模型，以合成能效高的代码并执行自动化重构。

作者强调，该分类法并非性能反模式的替代品，而是必要的扩展，因为仅针对速度进行优化并不保证能效。该工作的目标是将能耗意识引入标准的软件开发流程，从仅仅测量浪费转向主动消除浪费。