TRACY：评估基于大语言模型的代码翻译执行效率的基准测试
自动代码翻译是现代软件开发中的基础任务。尽管大语言模型(LLM)的出现显著提高了代码翻译的正确性，但执行效率这一关键维度却被忽视。为填补这一空白，我们引入TRACY，这是第一个专门设计用于评估LLM翻译代码执行效率的综合性基准。
TRACY通过LLM驱动的两阶段流程构建：初始阶段生成一套压力测试以放大性能差异，随后进行效率导向的任务修剪阶段，隔离出效率区分任务。最终基准包含1,011个跨C++、Java和Python的代码翻译任务，每个任务平均配有22.1个已验证的参考翻译和10个计算密集型测试。
lightbulb研究背景与动机
priority_high效率盲点
现有评估方法主要关注代码翻译的功能正确性，而忽略了执行效率这一关键维度。功能正确但效率低下的翻译在实际生产环境中可能引入严重的性能瓶颈。
trending_up性能差距
如图1所示，两个LLM生成的代码翻译在小型测试中功能正确且性能难以区分，但在计算密集型压力测试下，它们之间的性能差距可能高达600倍以上。
architectureTRACY架构与设计
source问题来源
TRACY的问题集基于广泛使用的Transcoder-Test，该基准包含568个来自GeeksForGeeks的多样化编程挑战，提供C++、Java和Python三种语言的参考代码。
insights基准统计
science压力测试生成阶段
code测试输入合成
利用高级LLM(GPT-4o)基于问题的参考代码生成多个测试输入合成器。每个合成器是一个自包含的Python函数，在执行时程序化输出测试输入。
verified测试验证
合成器生成的测试输入经过严格验证，确保它们在所有参考代码上都能成功执行且产生一致的输出，从而建立可靠的语言无关的测试基准。
filter_alt压力测试选择
从验证过的测试池中，选择计算需求最大的测试形成当前迭代的测试集。选择过程基于两个关键效率指标：执行时间和峰值内存使用量。
压力测试显著放大了平均执行时间(9.4倍)和峰值内存使用量(4.0倍)，有效暴露了简单测试会忽略的算法和习惯用法效率问题。
filter_list效率导向任务修剪阶段
rule可行性筛选
丢弃没有任何评估LLM能产生正确翻译的任务。这些任务无法提供效率分析的有效样本，因此不适合包含在基准中。
trending_up影响力筛选
丢弃执行成本微不足道的简单任务，要求至少有一个翻译在压力测试上超过执行时间阈值(0.001秒)或峰值内存使用阈值(1.5MB)。
diversity_3多样性筛选
丢弃正确翻译表现出可忽略性能差异的任务，要求执行时间或峰值内存使用量的变异系数(CV)高于阈值(0.05)，确保任务能有效区分模型在效率维度上的表现。
analytics评估结果与发现
主要发现
bug_report效率问题分类与案例分析
account_tree算法级差异 (14.8%)
将高效算法翻译为高复杂度变体，或未能采用目标语言中更高效的惯用算法。虽然频率最低，但破坏性最强，导致中位数时间减慢5.6倍。
code惯用和库使用低效 (61.9%)
选择功能正确但在目标语言中渐近或实际较慢的数据结构，或在效率关键的热循环中使用高开销API。这是最常见的低效类型，导致中位数时间减慢2.1倍。
memory资源管理和开销 (23.3%)
采用目标语言中非标准的分配策略，或为简单操作引入重量级抽象。这是内存低效的主要驱动因素，导致中位数内存消耗增加12.0倍。
我们的工作强调了在未来基于LLM的代码翻译中联合优化正确性和效率的必要性。TRACY作为首个专门评估代码翻译执行效率的基准，揭示了当前LLM在生成高效代码翻译方面的局限性，并为未来的研究提供了明确的方向。
我们已公开TRACY基准测试、构建框架和所有评估结果，以促进进一步研究，推动代码翻译领域向更高效、更实用的方向发展。