EffiPair: Improving the Efficiency of LLM-generated Code with Differential Execution Feedback
Authors: Samira Hajizadeh, Suman Jana
Organizations: Department of Electrical Engineering, Columbia University, New York, NY, USA · Department of Computer Science, Columbia University, New York, NY, USA
Large language models (LLMs) can generate functionally correct programs that differ substantially in execution efficiency. Existing inference-time optimization methods typically refine each candidate using pointwise runtime or profiling feedback, which identifies how costly an implementation is or where the cost arises, but offers limited guidance on how the computation should change. We introduce DIFFERENTIAL EXECUTION FEEDBACK (DEF), which compares implementations that are nearby in structural program space but separated in performance, turning their execution and implementation differences into directional optimization evidence. We demonstrate DEF in EffiPair, a training-free, test-time framework that pairs structurally similar programs with different efficiencies, distills their relative execution behavior into compact feedback, and iteratively refines a candidate pool. Across EvalPerf, Mercury, and ENAMEL, using GPT-4o mini, DeepSeek-V4.1 Flash, and GPT-5 mini, EffiPair achieves the highest value on each benchmark's official efficiency metric in all nine model-benchmark settings under matched evaluation conditions. Moreover, two contrastive refinement rounds improve efficiency over the selected initial draft in every setting while preserving or improving Pass@1. These results demonstrate the effectiveness of relational execution feedback as a lightweight signal for test-time code optimization.
Figures & tables
Figure 1: Overview of EffiPair . Given a coding task, the LLM samples N candidate programs. Candidates are checked for correctness and profiled for efficiency, then stored in a candidate pool. EffiPair selects a pair consisting of an efficient reference program p+ and a similar but less efficient candidate p− , summarizes their relative execution differences into compact Differential Execution Feedback (DEF) , and uses this signal to refine the program. The refined program is added back to the pool for subsequent rounds.
EvalPerf
Mercury
ENAMEL
Model
Method
DPS norm
Pass@1
Tok.
Beyond@1
Pass@1
Tok.
eff@1
Pass@1
Tok.
GPT-4o mini
Baseline (instruct)
75.50
89.83
0.2
81.06
92.19
0.5
49.78
83.80
0.3
EffiLearner-Gen
80.28
88.98
0.6
79.94
90.62
0.5
48.51
83.10
0.6
ECCO nl2code
79.49
82.20
0.3
79.68
89.45
0.5
53.99
83.80
0.7
ECCO exec-refine
74.88
67.80
0.7
80.32
89.84
1.2
47.99
75.35
1.3
ECCO self-refine
74.59
61.02
2.1
74.49
85.16
2.6
36.22
60.56
2.9
Table 1: EffiPair versus prior efficiency-oriented methods, all reproduced with the same models, decoding settings and evaluation harnesses. Each benchmark reports its official efficiency metric and Pass@1 (%). r0 is EffiPair ’s selected draft before refinement and r2 its output after two contrastive rounds; both are means over three independent runs, while other rows are single runs. Bold marks the best efficiency and Pass@1 within each model block. Tok. is thousands of tokens per task (prompt + completion) for that run; for EffiPair it covers the three sampled drafts and, in the r2 row, the two refinement rounds.
Method
DeepSeek-V4.1 Flash
Gemini 3.8 Flash
GPT-5.6 Luna
Claude Sonnet 5
eff@1 / Pass@1
eff@1 / Pass@1
eff@1 / Pass@1
eff@1 / Pass@1
Generation
Greedy Draft
55.73 / 93.66
60.88 / 97.18
55.29 / 90.14
56.01 / 94.37
Single Sampled Draft
65.30 ±2.34 / 93.66
78.99 ±1.34 / 96.71
64.36 ±0.71 / 89.20
62.76 ±0.96 / 93.66
Best-of-5
72.61 ±1.99 / 93.19
85.23 ±0.96 / 98.12
71.58 ±1.23 / 94.37
69.09 ±1.74 / 96.24
Pool Selection ( r0 )
71.52 ±1.32 / 94.84
83.70 ±0.81 / 97.42
69.91 ±1.06 / 93.66
67.38 ±1.20 / 94.60
Table 2: Component ablation on ENAMEL (142 tasks), reporting the official eff@1 / Pass@1 (%) metrics across four model families. We compare generation-only baselines with isolated refinement, random-pair refinement, and matched-pair refinement, with and without the corresponding constructed execution feedback (EF). In the last row, DEF is implemented by combining matched-pair refinement with execution feedback to create EffiPair . Best-of-5 is included as a generation-only control. All refinement methods operate on the same initial candidate pool and use the same correctness gate. Bold denotes the best reported value for each metric within each model.
Figure 2: Iterative refinement behavior of EffiPair on EvalPerf across evaluated models.
Arm
Contrast source
n
Mean gain (%)
Best seed (no refinement)
none
125
1.21
Solo (profile only)
none
125
1.19
Same-site pair
resampled variant
125
1.24
History pair
own prior version
107
1.16
Sibling pair
similar function
79
0.85
History + sibling
both
119
1.06
Table 3: EffiPair at repository scale on SWE-Perf (125 of 140 instances; exclusions in Appendix A.5 ). Each arm commits one patch per instance, the fastest correct member of its pool on EffiPair ’s own internal clock, which is not the metric reported here, and all arms and the expert patch are then measured together in one scoring session; Mean gain is the significance-gated improvement under SWE-Perf’s unmodified harness over that row’s n instances.
Appendix figures & tables7 assets
Supplementary material from the paper’s appendix.
Appendix
Figure 3: DPS, DPSnorm , and Pass@1 for various similarity thresholds on the EvalPerf benchmark.
Figure 4: Mercury #552 (DeepSeek-V4.1 Flash): the round-1 pair and the final refined program, each with its statement-level AST. Up to cosmetic edits, the pair differs only in how the table is stored (shaded) and the indexing this forces (blue); the refined program keeps the six states in scalars. ... marks omitted lines. Full case in Appendix A.4 .
draw
style
gate
wall (s)
workload (ms)
profile (ms)
1d7bfd0f
medium
ok
1.156
1085.6
1255.0
eb72593a
fast
ok
0.797
728.4
899.6
09cc3033
naive
timeout
30.031
–
–
Appendix
Table 4: Gate and clocks of the three draws (iteration 0).
run
iter.
source
Cand. B
gate
wall (s)
workload (ms)
profile (ms)
09cc3033
0
naive draw
–
timeout
30.031
–
–
1d7bfd0f
0
medium draw
–
ok
1.156
1085.6
1255.0
eb72593a
0
fast draw
–
ok
0.797
728.4
899.6
49b12e17
1
refines eb72593a
1d7bfd0f
ok
0.593
523.4
561.8
a4522979
2
refines 49b12e17
1d7bfd0f
ok
0.157
88.5
100.3
Appendix
Table 5: Every entry of the pool with its clocks.
pick
run
passes
runtime (s, median of 3)
Beyond@1
r0
eb72593a
yes
0.3756
54.0
r1
49b12e17
yes
0.2760
66.2
r2
a4522979
yes
0.0508
94.0
Appendix
Table 6: Committed picks and their official Mercury scores.
rep.
best draw ( r0 )
after round 1
after round 2
partner
naive (s)
1
1cefd2c5 (medium) 1258.7
bd58c82f 999.2
6b512ed5 162.3
aa9818e2
0.071
2
e543525f (fast) 957.3
31af93ac 313.2
c8225cda 195.4
0e89ba0d
0.064
3 ∗
eb72593a (fast) 899.6
49b12e17 561.8
a4522979 100.3
1d7bfd0f
30.031
Appendix
Table 7: Profile time (ms) of the best correct program after each stage in the three repetitions, the partner (Candidate B) of both rounds, and the wall time (s) of the naive draw’s gate run. ∗ The repetition shown above.
Code efficiency is a fundamental aspect of software quality, yet how to harness large language models (LLMs) to optimize programs remains challenging. Prior approaches have sought for one-shot rewriting, retrieved exemplars, or prompt-based search, but they do not explicitly distill reusable optimization knowledge, which limits generalization beyond individual instances. In this paper, we present EffiSkill, a framework for code-efficiency optimization that builds a portable optimization toolbox for LLM-based agents. The key idea is to model recurring slow-to-fast transformations as reusable agent skills that capture both concrete transformation mechanisms and higher-level optimization strategies. EffiSkill adopts a two-stage design: Stage I mines Operator and Meta Skills from large-scale slow/fast program pairs to build a skill library; Stage II applies this library to unseen programs through execution-free diagnosis, skill retrieval, plan composition, and candidate generation, without runtime feedback. Results on EffiBench-X show that EffiSkill achieves higher optimization success rates, improving over the strongest baseline by 3.69 to 12.52 percentage points across model and language settings. These findings suggest that mechanism-level skill reuse provides a useful foundation for execution-free code optimization, and that the resulting skill library can serve as a reusable resource for broader agent workflows.
Zimu Wang, Yuling Shi, Mengfan Li +4
Shanghai Jiao Tong University China · University of California, Berkeley USA · Columbia University USA +2
Harness optimization improves LLMs by refining reusable prompts and scaffolding, yet requires further adaptation for program generation tasks such as text-to-SQL and text-to-Python. Existing methods often rely on LLM reflectors to propose harness updates, which can fix observed failures but also disrupt previously correct behavior. Text-to-code tasks offer a natural way to mitigate this issue: we can execute generated outputs, allowing us to evaluate and verify the effects of proposed updates directly. Building on this signal, we introduce HERO Harnessing Evidence for Refinement and Optimization), which combines offline and test-time harness optimization. At the first stage, HERO learns reusable prompt updates from execution-verified successes and failures and validates candidate revisions before adoption. At test time, we treat the generated code as an instance-specific harness and refine it using execution feedback. Across four SQL, Cypher, and Python benchmarks, HERO achieves the best offline performance, improving pass@1 by 7.6 points over the initial prompt, while test-time refinement adds another 2.0 points and improves execution efficiency.
Mingyu Lu, Timothy Ossowski, Tristan Naumann +2
University of Washington · Microsoft Research · Recursion
Recent work has demonstrated the potential of large language models (LLMs) for program optimization, a key challenge in programming languages. We propose a blackbox adaptation method called Retrieval Augmented Search (RAS) that performs beam search over candidate optimizations; at each step, it retrieves in-context examples from a given training dataset of slow-fast program pairs to guide the LLM. Critically, we find that performing contextual retrieval based on an LLM-generated natural language description significantly outperforms retrieval based on the source code. We also propose AEGIS, a method for improving interpretability by decomposing training examples into ''atomic edits'' that are significantly more incremental in nature. We show that RAS performs up to 2.06× better than prior state-of-the-art blackbox adaptation strategies on optimizing C++ programs, and that AEGIS performs up to 1.37× better while making significantly smaller edits. We also show that using RAS improves the mean runtime percentile of Python programs by 10.27 compared to baselines.