💻 computer science

JETO-Bench: A Reproducible Benchmark for Execution Time Improvement Patches in Java

本文介绍了 JETO-Mine，这是一个用于生成 Java 执行时间改进补丁的可复现基准测试的新型可配置工具，该工具被用于创建 JETO-Bench（一个包含来自 174 个仓库的 660 个已识别补丁的数据集），并证明了当前的编码智能体（如 OpenHands）在这些任务上的成功率仅为 14.3%，同时强调了开源项目中性能相关测试的显著缺乏。

原作者： Khashayar Etemadi, Zhendong Su

发布于 2026-07-01

📖 1 分钟阅读☕ 轻松阅读

CC0 1.0

原作者： Khashayar Etemadi, Zhendong Su

原始论文根据 CC0 1.0（http://creativecommons.org/publicdomain/zero/1.0/）发布到公有领域。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你拥有一个由 Java（一种流行的编程语言）编写的庞大软件代码库。多年来，研究人员一直试图构建“机器人技工”（AI Agent），使其能够自动发现并修复这些代码中的漏洞。然而，大多数机器人只被训练用来修复功能性漏洞（functional bugs）——即软件崩溃或给出错误答案（比如计算器说 2+2=5）的错误。

那么**性能漏洞（performance bugs）**呢？这些是软件运行正确但极其缓慢的错误，就像汽车引擎运转正常，但由于动力不足，达到 60 英里时速的速度慢得离谱。直到现在，测试我们的机器人技工是否能修复这些“缓慢”问题一直非常困难，尤其是在 Java 环境下。

以下是对这篇论文内容的简单拆解：

1. 问题所在：“波动性”的 Java

在 Java 中修复速度问题，就像是在尝试为一个跑道表面每隔几秒就会变化的赛道计时。

挑战： Java 有一个特殊的“引擎”（JVM），它会随着使用时间的增加而变得更快（即时编译/JIT），并且偶尔会停下来清理工作空间（垃圾回收/Garbage Collection）。这使得测量速度变得非常棘手。一次测试看起来很慢，可能仅仅是因为计算机正在“预热”，而不是因为代码本身不好。
差距： 现有的用于修复速度问题的基准测试集（benchmark）大多存在于 Python 或 C++ 等其他语言中。Java 缺失了一个公平、可靠的测试集。

2. 解决方案：JETO-Mine（“淘金机”）

作者构建了一个名为 JETO-Mine 的工具。你可以把它想象成一台高科技的软件代码淘金机。

阶段 1：搜索（静态分析）： 这台机器扫描了 GitHub 上的数百万次提交（commits）。它使用一种智能 AI（大语言模型/LLM）来阅读开发者留下的“注释”，寻找暗示“我让这个运行得更快了”的线索。
阶段 2：实验室（动态分析）： 这是最关键的部分。一旦发现一个潜在的“速度修复”，JETO-Mine 会将代码放入一个 Docker 容器中。你可以把这想象成为每一次测试准备的一个密封且完全相同的实验室。
- 它将代码运行 30 次以获取平均值。
- 它使用严格的数学方法（统计测试）来证明提速是真实的，而不是由计算机的随机噪声造成的偶然现象。
- 它确保“修改前”和“修改后”的版本在完全相同的环境中运行，从而保证比较的公平性。
阶段 3：裁判（评估框架）： 这是一个检查机器人技工的修复是否有效的“裁判”。它运行新代码，检查其是否仍能通过所有原始测试，并测量其是否真的变快了。

3. 结果：JETO-Bench（“藏宝库”）

利用 JETO-Mine，研究人员创建了 JETO-Bench。

他们挖掘了 11 年的历史和近 180 万次代码变更。
他们找到了 660 个潜在的速度修复案例。
经过严格测试，他们验证了其中的 91 个作为“金标准”修复案例，这些案例保证可以运行且具有可复现性。
核心发现： 他们发现大多数开源 Java 项目并不具备能够证明某段代码运行更快的测试。这就像拥有一辆赛车，却没有任何秒表来证明它跑得有多快。这是一个巨大的测试缺口。

4. 实测：AI 能修复这些漏洞吗？

为了测试 JETO-Bench 是否有用，研究人员调用了一个领先的 AI 编程智能体 OpenHands，并要求它修复这 91 个速度问题。

得分： OpenHands 成功修复了 14.3% 的问题。
含义： 这个结果与针对 Python 和 C++ 的其他研究结果相似。这表明虽然 AI 正在进步，但修复“缓慢”的代码仍然非常困难。
加分项： “裁判”（评估框架）几乎自动捕捉到了所有的错误修复。如果 AI 尝试修复了错误的代码部分或者导致构建失败，系统会立即察觉。

5. 为什么这很重要

可复现性： 在此之前，如果你想测试一个新的速度修复工具，你只能寄希望于原始代码在多年后依然有效。JETO-Bench 提供了一个密封的“时间胶囊”环境（Docker），因此任何人今天运行完全相同的测试，都能得到相同的结果。
新的挑战： 论文强调，我们需要发明新的方式来编写测试，以测量速度，而不仅仅是测量正确性。
尚无“万灵药”： 该研究证实，即使是先进的 AI 智能体在处理性能优化时也会感到吃力，这表明这是一个需要更多研究的前沿领域。

简而言之： 作者构建了一台机器（JETO-Mine）来寻找并验证真实的 Java 代码加速案例。他们将这些案例打包成一个测试集（JETO-Bench），并证明了目前的 AI 机器人大约能修复 7 个速度问题中的 1 个，但同时也揭示了软件世界目前正缺乏能够妥善衡量速度提升的工具（测试）。

技术摘要：JETO-Bench 与 JETO-Mine

问题陈述

自动程序修复（APR）在诸如 Defects4J 和 SWE-Bench 等基准测试的推动下取得了显著进展。然而，这些基准测试主要关注功能性缺陷，使得非功能性问题（特别是执行时间性能）代表性不足。虽然针对 Python、C++ 和 .NET 的执行时间改进补丁（ETIPs）已存在相关基准（如 PIE、SWE-Perf、PerfBench），但 Java 领域仍处于空白。

由于 Java 特有的运行时特性，缺乏 Java 基准测试是一个关键问题。Java 对即时编译（JIT）和垃圾回收（GC）的依赖引入了执行时间测量的波动性。与 Python 或 C++（其执行时间更直接地与源代码挂钩）不同，Java 的测量需要严格处理 JVM 预热、GC 干扰和非确定性停顿。此外，现有的 Java 数据集（如 Yi 等人的研究）是固定的、不可扩展的，且缺乏容器化环境，随着项目依赖项的演变，这使得复现变得困难。最后，目前的性能基准通常无法通过用户定义的配置来扩展以收集新的真实世界补丁。

方法论：JETO-Mine

为了填补这些空白，作者提出了 JETO-Mine，这是一个可配置且可重用的工具，旨在自动创建真实 Java 项目中 ETIPs 的可复现基准。JETO-Mine 通过一个三阶段流水线运行：

1. 静态分析阶段

此阶段通过爬取 GitHub 仓库，利用用户定义的过滤器和基于 LLM 的分类器来识别潜在的 ETIPs。

仓库选择： 筛选活跃的 Java 项目（Java 8+，Maven Wrapper），并设定特定的星标数（star counts）和最近更新日期。
提交/PR 过滤： 分析默认分支的差异（diffs），保留仅影响 .java 文件、排除测试文件且修改文件数量有限的变更。
LLM 分类： 向 LLM 提供问题标题、描述和提交信息，以判断该变更是否主要解决执行时间改进问题。
去重： 将单个提交替换为其对应的 Pull Request (PR)，以捕捉完整的开发者意图，并基于代码差异进行去重。

2. 动态分析阶段

此阶段通过 Docker 将识别出的 ETIPs 转化为可执行、可复现的环境。

环境构建： 创建包含构建和测试项目所需的特定 Java 版本及依赖项的 Docker 镜像。
JVM 缓解措施： 为了对抗 JVM 的波动性，流水线在定时执行前会先执行一个专门的“预热”轮次（该轮次会被丢弃）。它在相同的 JVM 配置下多次运行测试套件（默认为 $n=30$ ），以最大限度地减少 GC 和 JIT 的方差。
统计测试： 对原始版本和补丁版本之间的执行时间进行配对单侧二项分布检验。如果补丁在特定测试类中显示出统计学意义上的显著改进（可配置 $p$ 值和最小改进百分比），则该补丁被视为 ETIP。
验证： 确保项目能够构建且所有测试均通过。如果补丁导致构建失败或破坏了现有测试，则将其排除。

3. 评估套件

此阶段提供用于定量评估生成的补丁和测试的工具。

补丁评估： 获取生成的补丁，将其应用于 Docker 容器内的原始代码，并运行统计测试以确定该补丁是否改进了执行时间。
测试生成评估： 支持评估生成“ETIP 检测器测试”（即能够从统计学上验证性能改进的测试）的工具。

核心贡献

1. JETO-Mine 工具

首个用于创建可复现 Java ETIP 基准的可配置工具。它允许研究人员根据特定的研究需求，通过自定义过滤器和统计严谨性水平，持续收集新的基准。

2. JETO-Bench 基准

利用 JETO-Mine，作者构建了 JETO-Bench，其包含：

660 个识别出的 ETIPs： 收集自 174 个开源 Java 仓库，跨越了 11 年的开发历史（涉及近 180 万个提交）。
91 个经过人工验证的可执行 ETIPs： 一个精选的子集，其中的补丁成功构建、通过测试，并关联了描述性的问题。这些补丁附带了用于完全复现的 Docker 镜像。
多样性： 该基准涵盖了多种项目类型（分布式系统、云原生框架），并包含多文件和多模块补丁，适用于评估仓库级修复工具。

3. 实证评估

作者在 91 个经过验证的 ETIPs 上评估了领先的开源编码智能体 OpenHands。

成功率： OpenHands 正确修复了 14.3% (13/91) 的问题。这与在其他语言类似研究中报告的成功率一致，表明 JETO-Bench 是一个可靠的基准。
故障定位： 在 27.5% 的案例中，OpenHands 修改了正确的代码位置，但未能生成语义正确的补丁，这突显了故障定位是关键的改进领域。
测试匮乏： 研究表明，开源 Java 项目普遍缺乏能够展示执行时间改进的测试。仅有 15% 的已验证 ETIPs 包含 JMH 基准测试，且现有的 JUnit 测试很少能检测到统计学意义上的性能差异。

结果与发现

精确度： 对随机选择的 50 个识别出的 ETIPs 进行人工分析，证实 JETO-Mine 的识别过程精确度为 96%。
可扩展性： 静态分析处理了 170 万个提交，耗时 478 小时（约 20 天），LLM 过滤成本为 5.33 美元。动态分析处理了 660 个 ETIPs，耗时 152 小时，Docker 镜像构建的中位时间为 34 分钟，中位大小为 790 MB。
智能体表现： OpenHands 的成功率为 14.3%，其中 22% 的生成补丁成功构建并通过了测试。评估套件有效地过滤掉了错误的补丁（仅 20/91 通过了所有测试），证实了基于执行反馈的价值。
测试生成差距： 尝试使用 OpenHands 为 91 个案例生成 ETIP 检测器测试的初步尝试仅成功了一个案例，这强调了生成能够可靠测量性能改进的测试之难度。

重要性与主张

论文声称 JETO-Mine 和 JETO-Bench 通过提供第一个可配置、可复现的 Java 执行时间改进基准，填补了自动化修复领域的关键空白。

可复现性： 通过利用 Docker 和统计测试来减轻 JVM 波动性，该基准确保了性能声明是客观且可复现的，这与以往的静态数据集不同。
可扩展性： 与固定数据集不同，JETO-Mine 允许社区根据特定的研究需求，持续扩展基准。
研究机会： 研究结果凸显了当前测试实践中的一个重大差距：缺乏验证执行时间改进的测试。作者认为，这为自动化性能优化和测试生成的未来研究提供了一个极具前景的机会。
基准效用： 对 OpenHands 的评估表明，JETO-Bench 有效地评估了先进编码智能体在 Java 性能任务上的能力与局限性，其结果与在其他语言中观察到的情况相符。

作者总结道，尽管目前的智能体在修复性能问题方面表现有限，但拥有像 JETO-Bench 这样严谨、可复现的基准，对于推动自动化性能优化和测试生成的未来发展至关重要。