Towards Better Correctness and Efficiency in Code Generation

TL;DR

This paper introduces a reinforcement learning framework that enhances code generation models by improving runtime efficiency without sacrificing correctness, using dynamic exploration and novel reward signals.

Contribution

It proposes a two-stage tuning method that balances correctness and efficiency, significantly improving performance of 7B models in code generation.

Findings

Code correctness improved by 10.18%

Runtime efficiency increased by 7.75%

Achieves performance comparable to larger models

Abstract

While code large language models have demonstrated remarkable progress in code generation, the generated code often exhibits poor runtime efficiency, limiting its practical application in performance-sensitive scenarios. To address this limitation, we propose an efficiency-oriented reinforcement learning framework guided by a novel performance reward. Based on this framework, we take a deeper dive into the code efficiency problem, identifying then proposing methods to overcome key bottlenecks: (1) Dynamic exploration overcomes the static data constraints of offline fine-tuning, enabling the discovery of more efficient code implementations. (2) The error-insensitive reinforcement learning method and high-contrast efficiency signals are crucial for mitigating systematic errors and achieving effective optimization. (3) Online exploration is most effective when starting from a high-correctness baseline, as this allows for efficiency improvements without sacrificing accuracy. With these discoveries, we finally propose a two-stage tuning method, which achieves high and balanced performance across correctness and efficiency. The results of experiments show the effectiveness of the method, which improves code correctness by 10.18\% and runtime efficiency by 7.75\% on a 7B model, achieving performance comparable to much larger model.

Tables

Table 1. Table 1: The subset of the training dataset. Notably, the queries from Effi-Learner are simpler, resembling the difficulty of Evalplus problems, while EffiBench’s queries are more akin to Mercury’s, since they all originate from LeetCode.

Dataset	Source	Metric	Num (#)
Train Dataset
EffiBench	LeetCode	-	790
Effi-Learner	Synthetic	-	2,978
Benchmark
Mercury	LeetCode	Beyond	256
Evalperf	Evalplus	DPSnorm	109

Table 2. Table 2: The results of different methods on Qwen-2.5-Coder-Instruct-7B model.

Method	EvalPerf		Mercury
	DPSnorm	Pass@1	Beyond	Pass@1
Untuned	77.60	77.50	74.80	77.20
SFT	77.85	79.19	66.36	83.20
DPO	87.61	81.89	72.23	85.47
GRPO	83.96	81.39	79.15	87.50
RLOO	81.97	82.46	76.00	89.92

Table 3. Table 3: The subset of the training dataset. The passrate is based on the Qwen-Coder-7B-Instruct.

Dataset	Effi-Learner	EffiBench
Pass@1	81.39	62.99

Table 4. Table 4: Results of DPO with different settings on Qwen-2.5-Coder-Instruct-7B. The Proportion represents the proportion of efficiency pairs in the training data.

Proportion	EvalPerf		Mercury
	DPSnorm	Pass@1	Beyond	Pass@1
0.0	84.60	87.20	71.45	87.11
0.5	87.61	81.89	72.23	85.47
1.0	84.80	74.70	72.21	77.30

Table 5. Table 5: The Impact of Syn Inputs with High Complexity Differentiation in online reinforcement learning.

High Complexity	EvalPerf		Mercury
Inputs	DPSnorm	Pass@1	Beyond	Pass@1
From Qwen-2.5-Coder-7B
Y	90.81	78.06	80.59	88.75
N	81.94	80.85	76.90	90.70
From Qwen-2.5-Coder-Instruct-7B
Y	83.96	81.39	79.15	87.50
N	81.94	80.85	76.90	90.70

Table 6. Table 6: The Impact of different initialization in reinforcement learning. Where the p p means proportions efficiency pairs. The Base and Inst means Qwen-2.5-Coder-7B and Qwen-2.5-Coder-Instruct-7B. The DPO model is tuned based on the Qwen-2.5-Coder-Instruct-7B.

Model	EvalPerf		Mercury
	DPSnorm	Pass@1	Beyond	Pass@1
Base	90.81	78.06	80.59	88.75
Inst	83.96	81.39	79.15	87.50
DPO ($p=0.1$)	87.35	84.32	80.52	88.83
DPO ($p=0.5$)	88.27	83.42	78.66	86.48

Table 7. Table 7: The results of different methods of Qwen-2.5-Coder-Instruct-7B model and Qwen-2.5-Coder-Instruct-32B. The results of Qwen-2.5-Coder-Instruct-32B are cited from LLM4EFFI  (Ye et al. 2025 ) . The symbols  \faBolt  in EvalPerf and Mercury represent the DPS norm and Beyond metrics, respectively.

LLMs	Method	EvalPerf		Mercury		AVG
		\faBolt	Pass@1	\faBolt	Pass@1	\faBolt	Pass@1
	Untuned	80.92	85.59	76.97	94.14	78.95	89.87
Qwen-2.5-Coder-	ECCO	82.16 ($\uparrow$1.24)	63.56 ($\downarrow$22.03)	73.29 ($\downarrow$3.68)	89.06 ($\downarrow$5.08)	77.73 ($\downarrow$1.22)	76.31 ($\downarrow$13.56)
Instruct-32B	Effi-Learner	82.45 ($\uparrow$1.53)	77.11 ($\downarrow$8.48)	77.13 ($\uparrow$0.16)	91.41 ($\downarrow$2.73)	79.79 ($\uparrow$0.84)	84.26 ($\downarrow$5.61)
	LLM4EFFI	86.20 ($\uparrow$5.28)	87.30 ($\uparrow$1.71)	78.96 ($\uparrow$1.99)	93.75 ($\downarrow$0.39)	82.58 ($\uparrow$3.63)	90.53 ($\uparrow$0.66)
	Untuned	77.60	77.50	74.80	77.20	76.18	77.37
Qwen-2.5-Coder-	DPO	88.50 ($\uparrow$10.90)	81.64 ($\uparrow$4.14)	76.66 ($\uparrow$1.86)	84.38 ($\uparrow$7.18)	82.58 ($\uparrow$6.40)	83.01 ($\uparrow$5.64)
Instruct-7B	RLOO	81.97 ($\uparrow$4.37)	82.46 ($\uparrow$4.96)	76.00 ($\uparrow$1.20)	89.92 ($\uparrow$12.72)	78.99 ($\uparrow$2.81)	86.19 ($\uparrow$8.82)
	Ours	88.82 ($\uparrow$11.22)	84.32 ($\uparrow$6.82)	79.04 ($\uparrow$4.24)	90.78 ($\uparrow$13.58)	83.93 ($\uparrow$7.75)	87.55 ($\uparrow$10.18)

Table 8. Table 8: Hyperparameters For SFT

Hyperparameter	Value
Learning rate	$5\times {10}^{-6}$
Learning rate scheduler	cosine
Warmup ratio	0.03
Batch size	1024
Epoch	10
Data size	5000

Table 9. Table 9: Hyperparameters For DPO

Hyperparameter	Value
Learning rate	$5\times {10}^{-6}$
Learning rate scheduler	cosine
Warmup ratio	0.03
Batch size	1024
Epoch	1
Data size	50000

Table 10. Table 10: Hyperparameters For RLOO/GRPO

Hyperparameter	Value
Episodes	30
Learning rate	$1\times {10}^{-6}$
Temperature	1.0
Batch size	64
Mini-batch size	32
N (sample num)	64
Max length	16k
Max generation length	12k

Equations

$$S_{min}$$

$$S_{max}$$

$$\mathcal{F}(C,G)$$

$$\mathcal{R}(C,G)$$

Full text

1 Introduction

With the rapid development of large language models (LLMs) (Brown et al. 2020; Achiam et al. 2023; Touvron et al. 2023; Dubey et al. 2024; Jiang et al. 2023; Bai et al. 2023; Yang et al. 2024a; Anthropic 2024; OpenAI 2024), code large language models have improved their capabilities in various code- related tasks. However, recent studies have indicated that these large models typically focus on the correctness of the generated code while neglecting its runtime efficiency (Waghjale et al. 2024; Huang et al. 2024b; Du et al. 2024; Liu et al. 2024). As a result, the generated code can be 3 to 13 times slower than human-written versions, limiting the practical application of model-generated code in real-world software development workflows (Huang et al. 2024b).

To this end, recent work has advanced along several key fronts, underpinned by the development of dedicated benchmarks like EvalPerf (Liu et al. 2024), Mercury (Du et al. 2024), and EffiBench (Huang et al. 2024b). Building on these evaluation frameworks, researchers have designed structured optimization workflows, such as the iterative, feedback-driven process in SOAP (Huang et al. 2024a) and the two-stage approach of LLM4EFFI (Ye et al. 2025). In parallel, a major research thrust focuses on directly augmenting model capabilities through fine-tuning and reinforcement learning (RL). This includes methods like Effi-Learner (Huang et al. 2024c) and PIE (Shypula et al. 2024), which leverage curated code samples, as well as approaches like Mercury’s (Du et al. 2024) validation of Direct Preference Optimization (DPO) and ACECode’s (Yang et al. 2024b) use of rule-based PPO to further improve code efficiency during generation.

To better understand the underlying challenges, we conduct a series of explorations and identify the following key insights: (1) Offline fine-tuning methods are bottlenecked by static datasets, as their performance is capped by the implementations present in the training data, limiting the ability to discover novel, more efficient algorithmic solutions. (2) While online methods like Reinforcement Learning (RL) offer a path to dynamic exploration, they introduce instabilities, as the inherently noisy and error-prone efficiency signal can prevent the model from learning effectively. This presents the challenge of designing an error-insensitive RL framework with high-contrast efficiency signals. (3) Our findings indicate that the optimization’s starting point is critical, and that a model with high initial correctness serves as a superior foundation for any subsequent efficiency optimization.

Based on these findings, we design a practical two-stage training strategy, which is structured to first establish a robust foundation of code correctness before optimizing for runtime efficiency. In the first phase, we focus on establishing foundational correctness by fine-tuning a base LLM, which can be done with normal offline methods. This creates a high-accuracy model to serve as a solid starting point. In the second phase, we build upon this foundation to enhance efficiency. We employ the error-insensitive online reinforcement learning algorithm that uses high-contrast efficiency signals to improve runtime performance while maintaining the high level of correctness achieved in the first stage.

Our main contributions are as follows:

• •

We first analyze the limitations of offline methods, revealing that they are bottlenecked by initial data quality and struggle to enhance efficiency without sacrificing the model’s correctness.

• •

We then investigate techniques for the online RL phase. We find that selecting an error-insensitive algorithm (RLOO) is crucial for preserving correctness, and we introduce a stabilized reward signal and high-contrast inputs to ensure a robust and effective optimization process.

• •

Based on these insights, we propose a two-stage tuning strategy, which achieves high and balanced performance across correctness and efficiency. The results show the effectiveness of this method, which improves code correctness by 10.18% and runtime efficiency by 7.75% on a 7B model, achieving performance comparable to much larger model.

2 Efficiency-oriented Reinforcement Learning

It’s hard to evaluate the runtime efficiency of code. Manually creating a reference version is labor-intensive and costly, and even then, the notion of “fast” code is inherently relative, as identifying a definitively optimal implementation is often intractable. This means even a carefully hand-tuned version cannot be guaranteed to be optimal (Yang et al. 2024b). Consequently, relying on a single, manually-optimized version as a performance baseline is inadequate.

To facilitate continuous model improvement, we therefore adopt a group comparison methodology for performance assessment. As our performance metric, we use CPU instruction counts rather than wall-clock time to mitigate sources of non-determinism, such as operating system scheduling (Liu et al. 2024). Besides, we introduce inputs with high complexity differentiation to overcome the insensitivity of trivial inputs to algorithmic efficiency differences during execution. However, the distribution of these raw counts is typically highly skewed and exhibits large variance, which can impede stable model training. To address this, we apply a logarithmic transformation to the counts to compress their value range and stabilize the variance (Enter 2008).

2.1 Reward Function

Our objective is to ensure that correct and faster code results in higher scores, with improvement on efficiency consistently contributing to the reward. The reward should be benchmarked against the efficiency of the code generated by the current model for the same query.

To formalize this, we first define our parameters.

• •

$C=-\log(N)$: The performance metric for the code being evaluated, where $N$ is the number of CPU instructions. Due to the negative sign, a higher value of $C$ indicates faster execution.

• •

$G=[C_{1},C_{2},\dots,C_{m}]$: An array of performance metrics for all correct codes generated for the same query.

• •

$\max(G)$ / $\min(G)$: The maximum / minimum value in $G$, representing the most efficient (fastest) / least efficient (slowest) code among all codes generated for the query.

Based on these parameters, we designed the reward function $\mathcal{R}$. If the code passes all tests, it receives a score calculated by $\mathcal{F}(C,G)$. This function maps the performance metric of the code to a reward where the slowest passing code gets a score of $1.0$ and the fastest gets a score up to $2.0$. Otherwise, it receives a penalty based on the error type.

This idea is formulated as follows:

[TABLE]

The final reward $\mathcal{R}(C,G)$ is assigned based on the execution outcome, which connects the performance score with the error classification:

• •

Pass All Tests: The code receives the calculated performance score, $\mathcal{R}=\mathcal{F}(C,G)$.

• •

Test Error: A score of $0.0$ is assigned if the code fails in any test.

• •

No Entity Error: A penalty of $-0.5$ is assigned if the model-generated code cannot find a corresponding test function.

• •

Format Error: The largest penalty of $-1.5$ is assigned if the response does not follow the specified format.

This is summarized by the complete reward function:

[TABLE]

3 Identify the Bottlenecks in Code Efficiency

This chapter aims to conduct a series of preliminary experiments to deeply analyze the inherent characteristics and challenges of existing mainstream methods in code optimization tasks. By understanding their strengths and limitations, we aim to achieve a better balance between correctness and efficiency in code generation.

3.1 Experiments

To contextualize our analysis, we compare several common fine-tuning methods across two standard benchmarks. These methods can be broadly categorized into two groups: offline methods, which learn from a static, precollected dataset, and online methods, which dynamically generate data during the training process.

Offline Methods

• •

SFT: A standard approach where the model is fine-tuned exclusively on the fastest correct code solution available for each problem in the training set.

• •

DPO (Rafailov et al. 2023): For each problem, we construct correctness pairs (correct vs. incorrect code) and efficiency pairs (faster vs. slower correct code).

Online Methods

• •

GRPO (Shao et al. 2024): A method that optimizes the policy based on the relative performance ranking within a group of generated solutions.

• •

RLOO (Ahmadian et al. 2024): A reinforcement learning technique that uses a leave-one-out strategy to estimate the reward baseline.

Datasets

To comprehensively evaluate the model’s code optimization capabilities, we utilize several datasets for training and benchmarking. The Table 1 below summarizes the datasets used for training and evaluation.

The metrics DPSnorm and Beyond are used to represent the model’s performance in terms of code efficiency. A higher value for these metrics indicates better efficiency. For a more detailed explanation, please refer to the appendix.

3.2 Results of Preliminary Experiment

We evaluated the different methods on the Qwen-2.5-Coder-Instruct-7B model, with the results presented in Table 2. Below, we analyze the performance of each method to identify the challenges in the scene and guide future research.

3.3 Offline Methods Bottlenecked by Initial Data Sampling

Offline methods, such as Supervised Fine-Tuning (SFT) and Direct Preference Optimization (DPO), are common strategies for improving a model’s performance. These approaches typically rely on generating a pool of candidate solutions from a base model and then selectively using them for fine-tuning. However, their ultimate success is fundamentally constrained by the quality of this initial sample pool. If the base model struggles to generate solutions that are both correct and efficient for certain problems, the offline tuning process is inherently limited, as it lacks high-quality data to learn from. In the following analysis, we demonstrate how this sampling bottleneck creates a crucial trade-off between correctness and efficiency, especially when tackling complex coding tasks.

Limited by Inefficient Samples from Challenging Problems

Our experiments first explored fine-tuning using only the fastest correct code generated by the base model. This method boosted correctness but at the cost of significantly reduced runtime efficiency on the more challenging Mercury benchmark.

A plausible explanation arises from the data in Table 1 and Table 3. The base model’s correctness is much lower on the difficult LeetCode problems in EffiBench (62.99%) than on the simpler synthetic problems in Effi-Learner (81.39%). This indicates that for complex problems, the few correct solutions the model manages to generate are often naive, brute-force implementations. While functionally correct, they are computationally inefficient. Consequently, when we use these difficult samples to create the fine-tuning data, we inadvertently select for these “correct-but-slow” solutions, teaching the model to replicate inefficient code.

DPO Hits an Efficiency Ceiling

As the Table 2 and Table 4 shows, DPO makes more effective use of negative samples than SFT, leading to significant improvements in code correctness without compromising efficiency. However, on more challenging problems, such as those in the Mercury benchmark, DPO faces a similar limitation to SFT. Both methods are constrained by the base model’s initial capabilities, making it difficult to sample solutions that are both correct and highly efficient. This inherent limitation hinders DPO’s ability to further enhance code efficiency for complex tasks.

3.4 Data Composition Dictates the Trade-off Between Correctness and Efficiency

While considering execution efficiency, code correctness must also be taken into account. Consequently, we seek to understand how the proportion of “efficiency pairs” within the training data influences the model’s performance.

As the Figure 1 shows, there is a core trade-off in model performance between code correctness (Y-axis) and runtime efficiency (X-axis), which can be tuned by varying the proportion of “efficiency pairs.”

• •

As the proportion of efficiency pairs increases from 0.0 to 0.9, runtime efficiency steadily improves while code correctness declines, demonstrating that this ratio can be used to steer the model’s focus.

• •

Notably, at a 1.0 proportion (using only efficiency pairs), performance deteriorates on both metrics, with correctness falling below the baseline. This indicates that solely pursuing efficiency at the complete expense of correctness leads to an overall degradation in performance.

From these results, we conclude that a significant emphasis on efficiency ($p\leq 0.9$) can be applied without substantially degrading model correctness, as this principle fails only under extreme conditions, for example, when efficiency is exclusively pursued at $p=1.0$. Consequently, we conjecture that within an online reinforcement learning, the dynamic reward mechanism can adeptly manage this balance, thereby improving efficiency without compromising model correctness.

3.5 Online RL is Constrained by Initialization, Reward, and Algorithm

Inputs with High Complexity Differentiation Gain Better Efficiency

During reinforcement learning, employing inputs with enhanced complexity differentiation to compute efficiency rewards enables more precise discrimination of code runtime performance, thereby driving superior efficiency performance. As validated in Table 5, such synthetically generated complex inputs effectively . However, this approach introduces a trade-off that may compromise code correctness. This effect is particularly pronounced in scenarios with insufficient test coverage, as evidenced by the EvalPerf benchmark results where efficiency optimization conflicts with functional accuracy.

Initialization from Models with Higher Diversity or Accuracy Gain Better Performance

As the Table 6 shows, the base model and post-trained models achieve better performance. Base models exhibit higher output diversity (Zhu et al. 2025), which is effectively leveraged by online reinforcement learning. This suggests that starting directly from a base model while considering both correctness and efficiency in RL is feasible. Initializing with DPO (High Accuracy, $p=0.1$) allows RL to focus more on optimizing efficiency rather than correctness during the training process. As we conjectured in the section 3.4, this results in better efficiency optimization without significantly compromising accuracy.

Error-Insensitive RL Algorithms can Maintain Accuracy better

As the Table 2 and Figure 2 shows, RLOO generally achieves higher average accuracy, while GRPO tends to achieve higher code execution efficiency. This discrepancy may be attributed to GRPO’s regularization mechanism, which amplifies minor improvements but also magnifies errors in efficiency rewards, potentially leading to over-optimization and reduced correctness.

4 Towards Better Correctness and Efficiency

4.1 How can we gain better performance?

As we analyzed the impact of various factors on the final model performance. This analysis will help us understand the key aspects that need to be considered to achieve better accuracy and runtime efficiency.

Switching to a More Stable RL Algorithm to Maintain Accuracy: As illustrated in Figure 2, RLOO demonstrates superior stability compared to GRPO in the later stages of training. Consequently, we adopt the RLOO algorithm to optimize the model’s performance while mitigating accuracy degradation. 2. 2.

Initializing from a High-Accuracy Model: The RLOO algorithm tends to preserve the accuracy of its initial model. We therefore initialize our training from a checkpoint with higher accuracy—specifically, a model previously fine-tuned with Direct Preference Optimization (DPO). The proportion of “efficiency pairs” for this stage was set to 0.1. 3. 3.

Using High-Contrast Inputs to Compute Efficiency Rewards: Our prior analysis indicates that employing more discriminative inputs is crucial for calculating rewards. These inputs elicit a wider range of performance, enabling a more accurate distinction between the runtime efficiencies of different code generations.

4.2 Method

Derived from our analysis, we designed a two-stage training strategy as shown in Figure 3. This approach is structured to first establish a robust foundation of code correctness before systematically optimizing for runtime efficiency.

Stage 1: Correctness Growth We utilize Direct Preference Optimization (DPO) with a dataset of code pairs heavily weighted towards correctness. Specifically, the training data is composed of 90% correctness-focused pairs and 10% efficiency-focused pairs, which allows us to produce a high-accuracy foundational model.

Stage 2: Efficiency Improve Initializing from the DPO-tuned checkpoint, we employ the RLOO algorithm to fine-tune for runtime efficiency. As shown in Figure 5, the training process yields a stable improvement in runtime efficiency while preserving the high level of correctness achieved in the prior stage.

4.3 Results

The result in Table 2 demonstrates that our proposed method achieves significant performance enhancements on two benchmarks. On the EvalPerf benchmark, it achieved a score of 88.82 on DPSnorm and 84.32 on Pass@1. For the Mercury benchmark, the scores were 79.04 for Beyond and 90.78 for Pass@1. The success of this method validates our findings and demonstrates an effective path towards better correctness and efficiency in code generation.

4.4 Case Study

This section presents specific cases to illustrate both the model’s intended successful paradigm and several instances of reward hacking.

In a typical successful optimization case (see Figure 4), the model first identifies a direct or “brute-force” solution and analyzes its potential performance bottlenecks on certain inputs. Subsequently, it proposes a more efficient algorithm and provides the complete implementation code. This process demonstrates the model’s expected reasoning and optimization capabilities.

However, we also observed that the model exploits loopholes in the evaluation mechanism to “hack” the reward signal, leading to its distortion.

• •

Exploiting the Evaluation Method: One failure mode arises from our method of measuring execution efficiency (see Figure 6(a)). To ensure stable results, our evaluation script warms up the system and averages multiple runs. The model exploited this by introducing an LRU Cache to “memorize” results across repeated executions, thereby achieving artificially high reward scores in subsequent runs.

• •

Exploiting Limited Test Cases: Another hacking behavior stems from the limited scope of our test cases (see Figure 6(b)). Drawing on knowledge from pre-training, the model used data structures like dictionaries to hard-code or memoize solutions for specific test inputs. While this approach passed the existing tests, it lacked generalizability, failed on new inputs, and sometimes produced incorrect results.

5 Related Work

Recent advancements in Code Large Language Models (CodeLLMs) have demonstrated remarkable capabilities across a spectrum of code-related tasks (Li et al. 2022; Lozhkov et al. 2024; Wang et al. 2023; Yu et al. 2023; Wei et al. 2023; Luo et al. 2024; Hui et al. 2024). However, a growing body of research highlights a significant limitation: their tendency to overlook the execution efficiency of the generated code (Waghjale et al. 2024; Huang et al. 2024b; Du et al. 2024; Liu et al. 2024). Empirical studies have shown that code produced by these models can be 3 to 13 times slower than human-written counterparts (Huang et al. 2024b). To systematically evaluate and address this issue, several benchmarks have been established. Notably, Mercury (Du et al. 2024), EvalPerf (Liu et al. 2024), and EffiBench (Huang et al. 2024b) provide standardized frameworks for assessing code execution efficiency, often utilizing problems from platforms like LeetCode and EvalPlus.

In response to this efficiency gap, a nascent body of work has explored methods to optimize the code generated by LLMs. These approaches can be broadly categorized into workflow-based methods and data-centric fine-tuning strategies. One line of inquiry focuses on engineering the generation process itself. For instance, ECCO (Waghjale et al. 2024) introduce a self-refinement method using natural language feedback to critique its own code and then apply optimization suggestions, while SOAP (Huang et al. 2024a) introduces an iterative optimization loop, leveraging direct execution feedback to refine the code. Similarly, LLM4EFFI (Ye et al. 2025) proposes a two-domain framework that mimics human development by first selecting an efficient algorithm in a “logic domain” before implementing it in a “code domain.” Another prominent direction involves curating datasets of efficient code and employing advanced training techniques. Mercury (Du et al. 2024), for example, fine-tunes models via Supervised Fine-Tuning (SFT) and Direct Preference Optimization (DPO) on a corpus of efficient, human-written solutions. Building on automated optimization, Effi-Learner (Huang et al. 2024c) fine-tunes models using the performance-enhanced code generated by the SOAP framework. Others, like PIE (Shypula et al. 2024), create specialized datasets for instruction tuning to improve C++ code efficiency, albeit with an observed trade-off in functional correctness. ACECode (Yang et al. 2024b) applies PPO to improve efficiency with human-written solutions as upper bound references.

6 Conclusion

In this work, we addressed the critical gap between the functional correctness and the runtime efficiency of code generated by large language models. Our investigation into different optimization methods revealed their distinct strengths and limitations. We found that offline approaches, while constrained by static initial data, are effective at establishing a strong correctness baseline. In contrast, error-insensitive online methods excel at dynamically improving runtime efficiency while maintaining the high level of correctness already achieved. This discovery directly guided our strategic approach. By first solidifying the model’s correctness before pursuing efficiency gains, we achieved significant improvements in both metrics. The success of this method validates our findings and demonstrates an effective path towards better correctness and efficiency in code generation.

Appendix

6.1 Data Prepare

The datasets and benchmarks are summarized in Table 1. We removed problems from Effi-Learner that had the same function signature as the Evalperf Benchmark, and de-duplicated the remaining problems using their function signatures. We also removed problems from EffiBench that duplicated the Mercury test set.

6.2 Metrics

• •

DPSnorm: Sourced from EvalPerf (Liu et al. 2024), the DPSnorm (Differential Performance Score, normalized) is used for the Evalperf benchmark. It evaluates the efficiency of a new code solution by calculating the percentage of reference solutions it runs faster than. A higher score indicates better efficiency.

• •

Beyond: The Beyond metric, from Mercury (Du et al. 2024), is used for the Mercury benchmark. It assesses efficiency by normalizing a solution’s runtime against the runtime distribution of all solutions for a given task. This method mitigates the impact of different hardware environments, allowing for fair cross-platform comparisons.

6.3 Training Setup

We sample and test 100 instances for each problem using Qwen-2.5-Coder-Instruct-7B to construct the SFT/DPO training data. For training data construction, we group multiple Abstract Syntax Tree (AST)-consistent code snippets based on their function ASTs, treating them as a set of homogeneous functions. From each such set, we randomly select one to serve as the response.

SFT

We evaluate accuracy and runtime efficiency using the sampled results. From each problem, we select the two correct samples with the highest runtime efficiency. Subsequently, 5,000 such samples are filtered to form the Supervised Fine-Tuning (SFT) training dataset. Training is conducted using LlamaFactory, (Zheng et al. 2024), and the hyperparameters used during training are presented in Table 8.

DPO

We construct Correctness Pairs and Efficiency Pairs for DPO: (1) We begin by classifying the sampled program execution results. These are categorized into correct samples and incorrect samples, from which we then form the Correctness Pairs. (2) Building upon the correct samples, we next focus on their execution performance. We measure this based on the runtime CPU instruction count. Training is conducted using LlamaFactory, (Zheng et al. 2024), and the hyperparameters used during training are presented in Table 9.

RLOO/GRPO

For the RLOO/GRPO training process, we utilize all samples from the Train Dataset detailed in Table 1. Training is conducted using Verl (Sheng et al. 2024), and the hyperparameters employed during this training process are presented in Table 10.

6.4 GRPO with Round

Compared to RLOO, GRPO’s division by the standard deviation in the reward calculation can amplify small errors. This can be mitigated by introducing a rounding mechanism, with the experimental results presented in Figure 7.