arXiv CSopen access

Multi-Source and Cross-Scenario Strategy-Guided Code Optimization

Multi-Source and Cross-Scenario Strategy-Guided Code Optimization Yuwei Zhao1 , Qianyu Xiao1 , Ye Cui1 , Yijun Yu2 , and Yingfei Xiong1,*

arXiv:2607.20353v1 [cs.SE] 22 Jul 2026

1

Key Laboratory of High Confidence Software Technologies (Peking University), Ministry of Education; School of Computer Science, Peking University, Beijing, China 2 The Open University, Milton Keynes, United Kingdom [email protected], [email protected], [email protected] [email protected], [email protected]

Abstract—Automated code optimization improves program performance by refactoring source code, and recent studies use LLMs to generate optimization patches. The newest approaches are strategy-guided: they summarize strategies from historical optimization commits as static analysis rules, and use these rules to match code locations for LLMs to optimize. However, these approaches have two limitations: (1) the strategies may come from other knowledge sources, such as textbooks and web pages, but the existing approaches cannot utilize them; (2) a strategy may be applicable to different scenarios, e.g., different programming languages, but existing approaches can only formalize strategies for the scenario to which the source commit belongs. To address these limitations, we propose MoST, an LLM-based code optimization framework that integrates multiple knowledge sources across scenarios. MoST uniformly represents items in different knowledge sources as evidence objects, clusters them in a cross-source and cross-scenario manner to identify strategies, and transfers them to the target scenario when necessary for generating static analysis rules. To implement this process, MoST employs a novel self-balanced weighted clustering algorithm to balance evidence objects from different knowledge sources, and a novel example transfer procedure to ensure the quality of the generated rules when transferring across scenarios. On a benchmark containing 151 C/C++, 150 Python, and 50 Rust historical optimization tasks, compared with SemOpt, MoST yields 24.44%-180.00% and 21.88%-37.50% more patches that are exactly the same as or semantically equivalent to developer patches, respectively. When optimizing 15 real-world projects, MoST achieves 19.72%-717.42% maximum improvements and 4.44%-258.17% average improvements for the performance tests in the projects, significantly outperforming SemOpt and Codex.

I. I NTRODUCTION Background. Automated code optimization refactors source code to improve program performance. Inefficient code can increase execution time, resource consumption, and operational cost, and affect user experience and service quality [1]–[4]. Although modern compilers implement small optimizations such as peephole optimization and common subexpression elimination [5], [6], many performance issues in real projects require large changes beyond what compilers can handle. Large language models (LLMs) provide a new opportunity for code optimization. Code LLMs have shown capabilities * Corresponding author: Yingfei Xiong ([email protected]).

in code understanding, generation, repair, and editing [7]– [10], and recent approaches utilize LLMs to change source code to optimize program performance [11]–[14]. However, directly asking an LLM to optimize code remains unstable: the model may miss optimizable code locations, or ignore a useful optimization strategy at the target location. As a result, the newest trend is strategy-guided: mining useful optimization strategies from historical commits to guide LLMs in code optimization [12], [15]. SemOpt is the state-of-the-art (SOTA) strategy-guided code optimization approach [15]. It extracts and clusters optimization strategies from historical optimization commits, and generates static analysis rules in Semgrep [16] for each cluster. These rules are then used to scan target code and locate positions where the strategy may apply. SemOpt then provides the matched location, strategy description, and related examples to an LLM for optimization patch generation. In this way, SemOpt generates significantly better optimization patches than directly asking the LLM to optimize code. Problem and Challenges. Existing strategy-guided methods, including SemOpt and others, still have two limitations. First, the strategy library is built from one class of knowledge sources: historical optimization commits. Optimization strategies may also appear in textbooks, manuals, Web pages, and other sources, but existing strategy-guided approaches cannot utilize them. Second, a strategy is formalized only for the scenario of its source evidence. Here a scenario denotes the context in which a strategy applies, such as a programming language and a target CPU architecture. For example, a Semgrep rule generated from a Java commit cannot be used for C code, though it may describe a general optimization strategy for any imperative programming language. Our Approach. To address these limitations, we propose MoST, a novel framework for Multi-source strategy construction and cross-Scenario strategy Transfer in LLM-based automatic code optimization. The basic idea is that LLMs have strong semantic understanding capabilities, and can identify and transfer optimization strategies across heterogeneous knowledge sources and scenarios. To uniformly represent the data items containing strategies in heterogeneous knowledge

sources, we introduce the concept of evidence object, capturing the description, the example, and the applicable scenarios of the strategy. With the help of LLMs, the data items in heterogeneous knowledge sources are first converted uniformly into evidence objects, then clustered based on the description to identify strategies in a cross-source and cross-scenario manner, and finally used to generate static analysis rules in the target scenario. Implementing this process has multiple challenges. • Balancing heterogeneous evidence during clustering (C1). The evidence objects from different knowledge sources may have different frequencies and qualities. For example, the commits in existing projects may be more noisy than optimization manuals, and contain repetitive strategies more often. Equal-weight clustering can let frequent commit evidence dominate and discard less frequent but valuable manual evidence. To address this challenge, we introduce a novel selfbalanced weighted clustering algorithm. This algorithm first searches for suitable weights for different knowledge sources plus other super parameters, and then applies weighted clustering such that different knowledge sources are balanced. • Reliable rule generation for cross-scenario transfer (C2). When a strategy cluster lacks sufficient examples in the target scenario, MoST has to construct the static analysis rules based on examples in other scenarios. We find that such a direct cross-scenario generation often leads to incorrect rules. To address this challenge, we introduce an example transfer procedure to first transfer examples from other scenarios to the target scenario. These examples are used not only to guide the generation of the rules, but also to validate the rules by checking whether a rule matches the pre-optimization example and does not match the postoptimization example. Evaluation. We evaluate MoST at two levels. First, the historical optimization reproduction experiment in Section IV evaluates whether MoST can reproduce historical patches written by human developers. The experiment covers 151 C/C++ tasks, 150 Python tasks, and 50 Rust tasks. Compared with SemOpt, MoST yields 24.44%–180.00% and 21.88%–37.50% more patches that are exactly the same as or semantically equivalent to developer patches, respectively. Second, the realworld project optimization experiment in Section V applies MoST to 15 real-world projects. MoST achieves 19.72%– 717.42% maximum improvements and 4.44%–258.17% average improvements for the performance tests in these projects, significantly outperforming SemOpt and Codex. Contribution. This paper makes the following contributions: • We formulate multi-source, cross-scenario strategy reuse for LLM-based code optimization, and introduce evidence objects for uniformly representing data items from heterogeneous knowledge sources and for transferring strategies across scenarios (Section III).

We propose self-balanced weighted clustering for balancing evidence objects from different knowledge sources, and an example transfer procedure for ensuring the quality of the generated static analysis rules for cross-scenario rule generation (Section III). • We evaluate MoST on 351 historical optimization tasks and 15 real-world projects. The results show that MoST produces more developer-equivalent patches and achieves higher performance improvement on real-world projects than all baselines (Sections IV and V). •

II. M OTIVATING E XAMPLE AND A PPROACH OVERVIEW A. An Optimization Strategy in a Document Figure 1a reproduces an excerpt from the Intel optimization document [17], with less relevant text omitted. The excerpt interleaves prose and partial C examples. Its prose describes loop blocking as dividing large traversals into cache-friendly blocks to reduce cache misses and improve data reuse, and its example rewrites a two-dimensional traversal over A and B by advancing outer indices by block_size. Figures 1b and 1c show the corresponding opportunity in a Rust loop. The original loop visits interior index pairs row by row, while the optimized loop visits TILE-sized regions to improve cache efficiency. At a high level, both changes replace full traversal with cache-friendly blocked traversal, so the strategy from the document can be used to optimize the Rust code. B. SemOpt and its Limitations As introduced before, SemOpt [15] is the SOTA strategyguided code optimization approach. Given a corpus of historical optimization commits, SemOpt first generates strategy descriptions from the commits and clusters the commits by the descriptions. In this way, each cluster represents an optimization strategy. SemOpt then generates static analysis rules from the commits in this cluster, and uses the rules to scan target code for optimization opportunities. When a rule matches, SemOpt asks an LLM to generate a patch by prompting it with the matched code, the strategy description, and the examples from the cluster. In this way, SemOpt guides the LLM to generate significantly better optimization patches with the precise location and strategy information. The running example demonstrates the limitations of SemOpt and other strategy-guided approaches. First, the source data is the raw document excerpt in Figure 1a, where prose and partial examples are mixed, while existing strategy-guided approaches could only utilize commits but not other knowledge sources. As a result, SemOpt cannot extract and normalize this document information, and the loop-blocking strategy would not enter its strategy library. Second, the strategy is expressed with C snippets and partial examples such that existing approaches could only generate static analysis rules for C programs based on the examples, while the target program in Figures 1b and 1c is in Rust, a different application scenario.

5.5.3 Loop Blocking. Loop blocking optimizes memory performance by reducing cache misses. It transforms a problem’s memory domain into smaller chunks instead of traversing the entire domain sequentially. Each chunk is chosen to fit the data for a computation in cache, maximizing data reuse. The manual also treats loop blocking as strip mining in two or more dimensions, and explains that blocking arrays into cache-sized rectangular chunks can eliminate redundant cache misses. ...

A. Original Loop float A[MAX, MAX], B[MAX, MAX] for (i=0; i<MAX; i++) { for (j=0; j<MAX; j++) { A[i,j] = A[i,j] + B[j, i]; } } B. Transformed Loop after Blocking float A[MAX, MAX], B[MAX, MAX]; for (i=0; i<MAX; i+=block_size) { for (j=0; j<MAX; j+=block_size) { for (ii=i; ii<i+block_size; ii++) { for (jj=j; jj<j+block_size; jj++) { A[ii,jj] = A[ii,jj] + B[jj, ii]; } } } }

fn blur(src: &[f32], dst: &mut [f32], w: usize, h: usize) { ... for y in 1..h - 1 { for x in 1..w - 1 { dst[y * w + x] = stencil(src, w, y, x); } ...

(b) Before-optimization code in the Rust target fn blur(src: &[f32], dst: &mut [f32], w: usize, h: usize) { ... const TILE: usize = 64; for y0 in (1..h - 1).step_by(TILE) { for x0 in (1..w - 1).step_by(TILE) { for y in y0..(y0 + TILE).min(h - 1) { for x in x0..(x0 + TILE).min(w - 1) { dst[y * w + x] = stencil(src, w, y, x); } ...

...

(a) Original document excerpt with strategy text and partial examples

(c) After-optimization code in the Rust target

Fig. 1: A document-sourced, cross-scenario motivating example. The Intel optimization document provides excerpted strategy prose and partial C examples rather than a commit-style before/after pair. The Rust target applies the same traversal strategy in another language.

C. Approach Overview Figure 2 summarizes how MoST addresses the example. First, we notice that though strategies may exist in heterogeneous data items in different knowledge sources, these data items can all be represented by several basic components: (1) A natural language (NL) description about when and how to apply the strategy, capturing the nature of the strategy beyond specific application scenarios and supporting crossscenario clustering. In our example, Figure 1a is the raw PDF excerpt, from whose prose MoST extracts the NL description of the C loop-blocking strategy. (2) A code-modification example consisting of a before-optimization code snippet and an after-optimization code snippet, useful in guiding the LLM to generate static analysis rules. The same excerpt contains partial C examples, so MoST normalizes them into complete before- and after-optimization snippets when constructing this field. (3) A scenario tag denoting the scenario of the codemodification example. For example, c__x86_64 describes a C-language optimization for the x86_64 architecture. We also allow a tag to capture multiple concrete scenarios, e.g., c__any describes a C-language optimization that can be applied to any architecture. We always use the most general scenario tag: the scenario for our example is c__any, as all popular architectures have cache. (4) A source type (e.g., commits, documents) records the type of the knowledge source where the data item comes from. We call such a uniformly represented data item an evidence object, and convert data items from different knowledge sources into evidence objects with the assistance of LLMs, corresponding to phase 1 in Figure 2. For example, given a document, we first divide it into multiple segments to fit into the context window, ask an LLM to identify evidence objects from each segment, and complete missing fields such as normalized before- and after-optimization snippets when necessary. Given a commit, we extract the code modification

example directly from the commit, and ask an LLM to generate the NL description based on the example and the commit message. Second, after we have a set of evidence objects, we can use the NL descriptions for clustering as in SemOpt. However, evidence objects from different knowledge sources differ in frequency and quality. For example, evidence objects from documents are usually of high quality and rarely duplicated, while evidence objects from commits often contain noise and duplicated strategies. If we directly cluster the two, the evidence objects from the documents would be treated as noise and ignored, though they in fact have better quality. To address this issue, in phase 2, MoST uses weighted density clustering [18], so document evidence can receive a higher weight and avoid being treated as noise. This requires selecting the document weight, description-similarity threshold, and minimum cluster size together, while the commit weight remains fixed at 1. MoST employs the self-balanced selection criterion. The key insight is that a good parameter configuration should preserve the scenario-level strategy counts obtained from single-scenario clustering after all evidence objects are clustered together. The system samples a bounded set of parameter values and selects the one that minimizes this scenario-level deviation without rule generation or LLM optimization. Third, in the original SemOpt, the next step is to sample commits from the cluster, generate b Semgrep rules from each sampled commit, and use rule agreement to rank matched code locations. This process can improve optimization stability. However, in MoST, a cluster may contain evidence from multiple scenarios, and directly generating a Rust rule from a C example can noticeably reduce rule correctness. To address this issue, in phase 3, MoST first computes a cluster weight k and uses it as the example budget. The sampling pool follows source weights: an evidence object with integer weight x contributes x copies of its code-modification

Fig. 2: The overall workflow of MoST. It first constructs evidence objects from multiple sources, then discovers strategy clusters, generates target-scenario rules through example transfer and validation, and finally uses validated rules to guide LLMbased code optimization.

example, while MoST prefers distinct examples and uses repeated copies only when distinct examples are insufficient. Target-scenario example construction then has three cases. If the cluster has at least k target-scenario example copies, MoST samples k of them. If it has some but fewer than k, MoST keeps them and instantiates the remaining examples from other-scenario references. If it has none, the strategy has not appeared in the target scenario before, so MoST first checks whether the strategy applies to that scenario; only applicable strategies are instantiated from other-scenario references. After the example budget is filled, MoST generates b Semgrep rules from each target-scenario example. In our running example, MoST first checks that loop blocking applies to Rust, then transfers the normalized C code-modification example to Rust. To further ensure the quality of the generated rules, MoST also adds functional validation after rule generation. For each rule generated from an example, we check whether the rule matches the before-optimization code and rejects the afteroptimization code. If not, we ask the model to regenerate. Combining the two procedures, MoST can generate highquality rules from the evidence objects. Finally, in phase 4, MoST proceeds in the same way as SemOpt: scanning the code with the generated rules and prompting the LLM to optimize the most matched code locations with their respective strategies. In our running example, we would get the optimized Rust code after this step. III. A PPROACH D ETAILS AND I MPLEMENTATION This section details the four phases outlined in Figure 2. A. Phase 1: Evidence object construction Following the representation introduced in Section II-C, MoST maps each input item to an evidence object e = ⟨P, E, T , y⟩,

(1)

where P is the NL description, E is the before/after codemodification example, T contains the applicable scenario tags,

and y is the source type. The source type remains attached so that later phases can trace the object’s origin and apply the corresponding clustering weight. The conversion differs by knowledge-source type. For commits, MoST follows the optimization-commit extraction process of SemOpt [15]: it takes the code change and its context as E and asks an LLM to summarize the strategy as P . For documents, the current implementation processes the Intel® 64 and IA-32 Architectures Optimization Reference Manual Volume 1 [17]. It divides the extracted PDF text into chunks, asks an LLM to identify optimization descriptions and applicability constraints, and generates a before/after example when the document does not provide one. This process yields 48,440 commit-derived evidence objects (27,463 C, 10,073 Python, 7,098 Java, and 3,806 Rust) and 189 document-derived evidence objects. To assign T , let L contain the properties used to describe a scenario; the current implementation uses programming language and target architecture. A scenario tag pairs each property li with a target value ti :
k T = (li = ti ) i=1 , li ∈ L. (2) A target is either one concrete value, such as rust or x86_64, or a named group of concrete values. For example, any denotes the group of all architectures considered by MoST. The system assigns the most general valid target: an architectureindependent strategy receives any, whereas a strategy that depends on an instruction set or microarchitecture receives the corresponding concrete architecture. A target scenario matches a tag when its value in every property either equals the tag’s concrete value or belongs to the tag’s group. B. Phase 2: Self-balanced weighted strategy clustering As described in Section II-C, MoST measures similarity using only the NL descriptions and applies weighted density

clustering [18]. The three clustering parameters are the document weight wd , the description-similarity threshold τ , and the minimum cluster size smin . The commit weight is fixed at 1, and smin specifies the minimum weighted evidence support required to retain a cluster. The self-balanced selection criterion chooses the three parameters jointly from a bounded candidate set Θ, sampled before evaluation as in random hyperparameter search [19]. For each candidate θ and scenario tag T , MoST takes the single-scenario clustering result as the reference count KT , clusters all evidence objects using θ, and obtains MT (θ), the retained native strategy-cluster count for T . To preserve this count without excessive inflation, and following log-ratio analysis for relative data [20], MoST measures rT (θ) = log

MT (θ) + ϵ , KT + ϵ

(3)

where ϵ > 0 avoids zero-count divisions. The per-group loss is ℓT (θ) = |rT (θ)| + λ max(0, −rT (θ)). (4) The first term penalizes both under- and over-clustering, while the second adds a larger penalty for losing strategy coverage. For T+ = {T | KT > 0}, the criterion scores each candidate by 1 X L(θ) = ℓT (θ), (5) |T+ | T ∈T+

and selects θ∗ = arg min L(θ). θ∈Θ

(6)

This selection reruns only clustering, without LLM calls, Semgrep rule generation, or performance evaluation. The selected configuration is document weight 3, similarity threshold 0.76, and minimum cluster size 5; Section IV-C compares this automatically selected configuration with nearby alternatives. After the selected clustering run, MoST assigns each strategy cluster an integer example budget:     X  1 1 W (C) =  wy(e) +  . (7) |S(C)| 2 e∈U (C)

Here, U(C) is the deduplicated evidence in C, S(C) is the set of source scenarios represented in C, and wy(e) is the selected source-type weight of evidence e. The averaging prevents a multi-scenario cluster from receiving a larger budget only because it appears in more scenarios; W (C) is used as the target-scenario example budget in Phase 3. C. Phase 3: Target-scenario rule generation and validation For each strategy cluster C and target scenario T ∗ , MoST sets nC = W (C) and selects nC NL-description–example pairs from which to generate rules. For sampling, an evidence object with integer source weight x contributes x copies of its example; MoST prefers distinct examples and uses repeated copies only when the distinct examples are insufficient. Let m(C, T ∗ ) be the number of weighted example copies in C

TABLE I: Per-scenario strategy-cluster and rule-generation scale. Metric

c c c java any arm64 x86 64 any

Clusters with 271 exact-tag evidence Clusters added 24 from other-tag evidence All target-scenario 295 clusters Generated 9,735 Semgrep rules

python any

rust any

rust rust arm64 x86 64

0

5

39

63

38

0

0

24

24

104

85

130

133

137

24

29

143

148

168

133

137

730

900 4,395

4,475 5,135 4,345

4,455

whose tags exactly match T ∗ . Since nC is rounded from the average weighted evidence strength, the cluster-level sampling pool contains enough copies to fill the budget from other scenarios when exact-target examples are missing. The selection has three cases: 1) If m(C, T ∗ ) ≥ nC , MoST samples nC exact-tag pairs. 2) If 0 < m(C, T ∗ ) < nC , it retains the exact-tag pairs, samples the remaining nC − m(C, T ∗ ) pairs from other scenarios in C, and asks an LLM to transfer their descriptions and examples to T ∗ . 3) If m(C, T ∗ ) = 0, an LLM first determines whether the strategy applies to T ∗ . If it does, MoST transfers nC sampled pairs as above; otherwise, it skips C for this target. Rule generation starts only after this step fills the targetscenario example budget for the retained cluster–target pair. For each selected or transferred pair, the LLM independently generates b Semgrep rules [16]. Each rule is first checked for successful parsing and execution. It must then match the before-optimization code in the example and reject the afteroptimization code. On a parsing error, false negative, or false positive, MoST returns the failure and relevant location to the LLM for regeneration. Only rules passing both checks are used for T ∗ . This check is stronger than SemOpt’s execution-only test for LLM-generated rules, which can admit rules with false positives, false negatives, or unclear semantic boundaries [21]– [23]. The selected clustering run produces 356 strategy clusters, including 39 cross-scenario clusters. Table I reports how these clusters are used for each target scenario. A cluster with exact-tag evidence contains at least one evidence object whose scenario tag is exactly the target tag. A cluster added from other-tag evidence has no such object, but passes the applicability check and supplies examples that are transferred to the target scenario. The third row sums these two groups, and the final row reports the Semgrep rules generated from them. D. Phase 4: Optimizer The final phase follows SemOpt’s optimizer [15]. Given a target function and scenario T ∗ , MoST loads the validated rules whose tags match T ∗ and scans the function. Each match identifies a code location and an optimization strategy. MoST merges matches only when both are the same, ranks each

B. RQ1 Comparison with Baselines To evaluate MoST on historical optimization tasks, we compare it with Direct Prompt, RAG, and SemOpt. Figure 3 reports successful-task proportions on the C/C++, Python, and Rust benchmarks, which contain 151, 150, and 50 tasks, respectively. RAG

SemOpt

16

22

71

64

9

33 47

44

3

11

40

64 78 1

4 5

14

27 40 53 6

20

19 29 43

40

5

45 56

60

87

SemEqv

15

EM

MoST

10

Direct

28

A. Experimental Setup 1) Benchmark: This experiment uses historical optimization tasks. Each task records the codebase, commit hash, and complete pre- and post-commit functions. The pre-commit function is the tool input; the post-commit function forms the developer patch and ground truth. We directly reuse the SemOpt C/C++ and Python benchmarks, which contain 151 and 150 optimization tasks, respectively [15]. Because SemOpt does not include a Rust benchmark, we follow the same process to build one. From the 100 most-starred Rust codebases on GitHub, we collect 1,008,176 main-branch commits, retain commits modifying only a single Rust function, filter optimization-related commits by keywords and code modifications, obtain 732 commits, and randomly sample 50 optimization tasks. Because the benchmarks come from historical GitHub commits, they may overlap with data sources used by MoST and the baselines. To mitigate data leakage, we exclude exact matches to the current task commit or task code from all available data; the remaining data can still support strategy construction, retrieval, and optimization. 2) Baselines: We compare MoST with three baselines. Direct Prompt This baseline provides the current function in a static prompt and asks the LLM to generate optimized code. Retrieval Augmented Generation (RAG) Following Gao et al. [24], RAG retrieves the four most similar optimization examples from the available data with BM25, sorts them in ascending similarity order, and prompts the LLM with them and the current code. The current task commit and exact code matches are excluded. SemOpt For C/C++ and Python, we reuse the original SemOpt tool implementation. Since the original SemOpt paper does not include a Rust version, we reimplement it according to the SemOpt workflow [15]. We omit RAPGen [12] and Clang-Tidy [25] because SemOpt has already systematically compared with them and shown that they are weaker on historical optimization tasks [15].

4

IV. E VALUATION 1 H ISTORICAL O PTIMIZATION TASK R EPRODUCTION RQ1 Compared with the baselines, can MoST produce more successful optimizations? RQ2 How important are the two core design components of MoST? RQ3 Are the optimization suggestions generated by MoST practically applicable?

3) Evaluated LLMs: We use DeepSeek-V4-Pro [26] in all experiments and additionally run GPT-5.2 [27] on C/C++. DeepSeek-V4-Pro is the primary optimizer model because it was strong and stable during our experiments. GPT-5.2 provides a supplementary closed-source setting for C/C++; due to budget constraints, we do not extend it to Python and Rust. We set temperature to 0 and keep all other provider settings at their defaults. 4) Metrics: To evaluate optimized-code correctness, we reuse the two metrics used by SemOpt [15]. • Exact Match (EM) removes comments, indentation, and whitespace from the developer ground truth and generated code, and checks whether the normalized strings are identical. • Semantic Equivalence (SemEqv) compares the generated patch with the developer patch and judges whether they are semantically equivalent. 5) Implementation Details: Following existing work, all LLMs use temperature 0 [15], [24]. Each optimization task is repeated 3 times, and a method succeeds if at least one generation satisfies the corresponding metric. Following SemOpt’s experimental setting [15], we set the rule-generation budget to b = 5 Semgrep rules per sampled commit or target-scenario example.

Success (%)

merged location–strategy pair by the number of supporting rules, and retains the top N = 25 pairs. For each retained pair, the LLM receives the target function, matched location, strategy description, related target-scenario examples, and context indicated by T ∗ . For an architecturespecific target, this context can include the processor model, architecture, and available instruction sets. The LLM then generates the optimization patch.

0 C/C++ C/C++ Python Rust DS GPT DS DS

C/C++ C/C++ Python Rust DS GPT DS DS

Fig. 3: Performance comparison across languages and models. Bar heights show successful optimization proportions, and integer labels show successful-task counts. DS and GPT denote DeepSeek-V4-Pro and GPT-5.2, respectively. 1) Comparison to SemOpt: As shown in Figure 3, MoST obtains higher results than SemOpt under all language and model settings, improving EM by 24.44%–180.00% and SemEqv by 21.88%–37.50%. SemOpt derives optimization strategies from historical optimization commits and uses rules to locate optimizable code regions [15], whereas MoST uses multi-source evidence objects, transfers examples to target scenarios when needed, and validates target-scenario rules before optimization. These results suggest that multi-source strategy construction and reliable rule generation complement

the coverage limits of a single historical-commit strategy library. 2) Comparison to Direct Prompt and RAG: Direct Prompt asks the LLM to generate an optimization result from the input function, mainly relying on the model’s internal code knowledge and the prompt. RAG further provides similar historical optimization examples from the available data. However, neither method explicitly abstracts reusable optimization strategies or uses rules to locate where an optimization should be applied. Figure 3 also shows that MoST outperforms Direct Prompt and RAG under all settings, improving successful optimizations by 480.00%–1300.00% and 93.94%–250.00%, respectively. Direct LLM generation is unstable for reproducing developer optimizations. RAG improves over Direct Prompt with similar examples, but remains below SemOpt and MoST, suggesting that retrieved examples cannot replace strategylevel abstraction and rule-guided localization. 3) Cross-language Results: MoST achieves the highest success rate on C/C++, Python, and Rust, so its benefit is not limited to one language. Compared with SemOpt, MoST improves successful optimizations on Rust by 37.50%–180.00%, above the 21.88%–48.28% range on C/C++ and Python. Since C/C++ and Python have more historical optimization data, SemOpt’s single-language strategy libraries already have relatively high coverage; Rust has less data and benefits more from multisource strategy construction and cross-scenario transfer. Answer to RQ1 MoST produces more successful optimizations than Direct Prompt, RAG, and SemOpt on C/C++, Python, and Rust historical optimization tasks, improving over SemOpt by 24.44%–180.00% in EM and 21.88%–37.50% in SemEqv, and improving the number of successful optimizations over Direct Prompt and RAG by 480.00%–1300.00% and 93.94%–250.00%, respectively.

TABLE II: Strategy-library parameter configurations. Param.

C1

C2

C3

C4

C5

C6

C7

C8

C9 C10

Doc. weight 3 3 3 3 4 4 5 5 3 5 Threshold 0.78 0.77 0.76 0.74 0.90 0.91 0.90 0.91 0.91 0.84 Min size 5 5 5 6 4 4 5 5 3 5 Balance loss ↓ 3.57 3.26 2.93 3.09 4.58 4.72 5.48 5.68 3.44 4.01 EM 12 13 14 11 12 12 9 9 13 10

TABLE III: Ablation study on the C/C++ benchmark with DeepSeek-V4-Pro. Approach MoST w/o weighted clustering w/o reliable rule generation

EM

SemEqv

56 (37.09%) 50 (33.11%) 28 (18.54%)

78 (51.66%) 71 (47.02%) 44 (29.14%)

w/o weighted clustering. This variant sets all source-type weights to 1 and keeps other settings unchanged, evaluating source weights and weighted clustering. w/o reliable rule generation. This variant disables example transfer and directly asks the LLM to generate Semgrep rules from available cluster evidence. It also disables functional validation, so rules are not checked against target-scenario before/after examples. As shown in Table III, removing weighted clustering reduces successful optimizations by 8.97%–10.71%, and removing reliable rule generation causes a larger 43.59%–50.00% decrease. These results suggest that weighting helps protect high-value but low-frequency sources, while target-scenario examples and functional validation are important for reliable rule-based localization. Answer to RQ2 The balance loss selects the configuration with the best pilot-study EM; removing weighted clustering and reliable rule generation reduces successful optimizations by 8.97%–10.71% and 43.59%–50.00%, respectively.

C. RQ2 Ablation Study

D. RQ3 Practical Applicability

We evaluate the two core components of MoST on the C/C++ benchmark with DeepSeek-V4-Pro fixed as the evaluated LLM. Section III-B describes how MoST selects document weight 3, similarity threshold 0.76, and minimum cluster size 5 by minimizing a clustering-only balance loss. The loss uses scenario-level strategy-count deviation with ϵ = 1 and λ = 1, and requires no rule generation, LLM optimization, or performance evaluation. To check whether this low-cost selection matches optimization outcomes, we use a disjoint 45task pilot set, with 15 tasks per language and no overlap with the formal benchmark; the C/C++ and Python sets reuse the SemOpt setting [15], and the Rust set samples from GitHubstar ranks 101–200 after the same filtering process. Table II reports the ten parameter configurations, their clustering-only balance losses, and pilot-study EM results. C3 has both the lowest loss and the best pilot-study EM, supporting the parameter-selection criterion. Table III reports the complete method and two ablation variants.

To evaluate MoST’s practical value, we measure how many optimization suggestions are acceptable in realistic settings. We consider a suggestion valuable if it preserves the original semantics and improves performance, such as execution speed or resource efficiency, even without exactly matching the original commit’s optimization. Due to manual-inspection cost, we evaluate this question only on the C/C++ benchmark with DeepSeek-V4-Pro. Among MoST’s optimization suggestions, 89.70% satisfy this criterion, indicating that most are practically applicable in realistic settings. This rate is close to the 89.86% reported by SemOpt with DeepSeek-V3 [15], suggesting comparable practical applicability. Answer to RQ3 On the C/C++ benchmark with DeepSeekV4-Pro, 89.70% of MoST’s optimization suggestions are manually judged acceptable, close to SemOpt’s reported 89.86% with DeepSeek-V3.

V. R EAL - WORLD P ROJECT O PTIMIZATION RQ4: On real-world projects, can MoST produce more correct optimization results with performance improvements than SemOpt and Codex Agent? RQ5: What source and transfer provenance do MoST’s effective optimization results have? A. Experimental Setup 1) Benchmark Projects: We evaluate MoST on five C/C++ projects, five Python projects, and five Rust projects. The ten C/C++ and Python projects reuse the real-world project optimization subjects from SemOpt [15]. The five Rust projects are newly collected to evaluate practical optimization after extending cross-scenario transfer to Rust. C/C++ Projects: We reuse the five C/C++ projects from SemOpt: RocksDB [28], Redis [29], gRPC [30], LevelDB [31], and spdlog [32]. Python Projects: We reuse the five Python projects from SemOpt: Click [33], Flask [34], Jinja2 [35], Requests [36], and Scrapy [37]. Rust Projects: We collect Rapier [38], image [39], regex [40], sqlparser [41], and Tokio [42]. These projects cover a physics engine, image processing, regular expressions, SQL parsing, and asynchronous runtime support, representing different types of performance-sensitive Rust code. We select them for stable buildable versions, runnable performance tests, and performance-critical code suitable for automated optimization. Each project provides a relatively complete performance test suite for quantitative optimization measurement. For each project, we clone a fixed version, write scripts to compile C/C++ and Rust code or install the Python package, and run built-in unit and performance tests. The 15 projects contain 259 performance data points in total, with 2–45 per project. Each data point usually reflects one functionality or performance metric. 2) Baselines: We compare two types of baselines and report MoST as the method proposed in this paper. SemOpt: SemOpt is the original strategy-guided code optimization method. We follow and reuse the implementation and workflow from its paper [15]. For Rust projects, we reproduce a Rust version under the same workflow and use the same project-level evaluation protocol. If a Rust project has no SemOpt optimization result above 5%, the original workflow that first filters results above 5% and then combines them cannot continue; in this case, we select the evaluable optimization result with the best performance as the final result. Codex Agent: The Codex Agent baseline uses OpenAI Codex [43] to directly modify real projects, with three model configurations: gpt-5.3-codex-spark (Codex Spark) [44], gpt5.4-mini (Codex 5.4 Mini) [45], and gpt-5.4 (Codex 5.4) [46]. We use the parenthesized names as table abbreviations. All Codex results use the 30-minute version with high thinking mode. In the prompt, we provide the project repository, build

script, test script, localized hotspot functions, performance optimization objective, and subsequent performance testing method. 3) Models: SemOpt and MoST both use DeepSeek-V4Pro [26] as the optimizer model, keeping the default inference settings. 4) Metrics: For each optimization result, we apply it to the project, compile C/C++ and Rust code or install the Python package, and run project tests. Only passing results enter the performance statistics. For evaluable results, we run performance tests 6 times for both unoptimized and optimized versions, discard the first run, and average the remaining 5 runs. All project-level performance changes in Table IV satisfy Welch’s t-test at p < 0.05 [47]. This repeated-measurement protocol is consistent with prior performance measurement studies [13], [48]–[51]. Different test cases may report performance metrics in different directions. If a larger value is better, let x and y denote results before and after optimization, respectively, and compute the improvement ratio as y−x x . If a smaller value is better, the improvement ratio is computed as x−y y . We use the following metrics to evaluate optimization effectiveness. #Pts.: The number of data points used for performance statistics in each project. A data point corresponds to one test case or performance metric with independently computable performance improvement. • Max / Avg: The maximum and average performance improvement ratio of a method over all data points in the project. • # ≥ n%: The number of data points whose performance improvement ratio reaches at least n%. Because Table IV separately reports total data points per project, the ≥5% and ≥10% columns report only threshold-reaching counts. •

5) Implementation Details: For each project, MoST identifies hotspot functions through profiling, generates candidate optimizations for them, and evaluates candidates under the same project testing and performance measurement protocol. For C/C++ projects, we use perf [52] and gcov [53]. For Python projects, we use cProfile [54] and line profiler [55]. For Rust projects, we use perf and locate hotspot functions using function symbols in the benchmark harness. We treat functions whose execution time exceeds 0.1% of total runtime as hotspot functions. For MoST and SemOpt, we follow the SemOpt projectlevel setting [15]: a candidate is eligible for composition if it improves at least one data point by more than 5% and degrades no other data point by more than 2%. For each hotspot function, we keep the eligible variant with the highest total improvement score, computed as the sum of improvement ratios over all data points, preserve the original function when none is eligible, and assemble the selected variants into the final optimized project version. For RQ4, each project-method pair contributes one final project-level result; Codex Agent’s project patch is evaluated as that result. We then compute Max, Avg, ≥5%, and ≥10% over all data points. To reduce

performance fluctuations, we avoid other resource-intensive programs during performance tests. B. RQ4: Real-world Optimization Results Compared with Baselines RQ4 evaluates project-level performance results of MoST, SemOpt, and Codex Agent on real-world projects. Table IV records each method’s final result by project. All results use the same build, test, and performance measurement protocol. MoST results. As shown in Table IV, MoST achieves the highest maximum performance improvement on all 15 projects and the highest average performance improvement on 14 projects. The maximum performance improvement ranges are 19.72%–249.75% on C/C++, 82.62%–717.42% on Python, and 20.22%–384.42% on Rust projects. The corresponding average performance improvement ranges are 5.88%–16.69%, 43.75%–258.17%, and 4.44%–42.82%. These results show that MoST’s gains do not depend on a single language or project and can produce measurable performance improvements in real projects from different ecosystems. Comparison with SemOpt. Compared with SemOpt, MoST achieves a higher maximum performance improvement on every project, with relative improvements of 14.52%–531.88%. For average performance improvement, MoST is lower by 0.02% on LevelDB, while the other projects show relative improvements of 2.01%–675.05%. This indicates that MoST can find higher-benefit optimization results on individual projects and improve overall average performance on most projects. Comparison with Codex Agent. Compared with Codex Agent, MoST’s advantage is more stable. Using the Codex version with the highest maximum performance improvement on each project as the comparison point, MoST improves Max by 3.62%–6329.95% on comparable projects where that Codex version obtains a positive improvement. For Avg, MoST also exceeds the best-performing Codex version on each project, with relative improvements of 4.74%–27288.89%. Codex can produce effective optimizations on some projects, and Codex Spark exceeds MoST on Flask in both threshold-count metrics, # ≥5% and # ≥10%. However, although Codex Spark has a complete testing environment for compiling and running code, it has no usable performance result on Rapier because it fails at compilation, suggesting limitations in general code agents for project-level code optimization. Answer to RQ4. On the 15 real-world projects, MoST ranks first in Max on all projects and in Avg on 14 projects, with relative improvements of 14.52%–531.88% in Max over SemOpt, a 0.02% Avg decrease on LevelDB and 2.01%–675.05% Avg improvements on the other projects over SemOpt, and 3.62%–6329.95% in Max and 4.74%– 27288.89% in Avg over the best Codex version on comparable projects. C. RQ5: Strategy Source and Transfer Analysis RQ5 analyzes the source and cross-scenario exampletransfer provenance of MoST’s effective optimization results.

Table V aggregates effective optimization results by language and traces their sources. Unlike RQ4, RQ5 counts all MoST-generated effective optimization results before projectlevel final selection; multiple results from the same project, hotspot function, or selected rule are counted separately when they are distinct evaluated optimization outputs. Effective denotes optimization results that pass project tests and obtain a statistically significant positive performance improvement (p < 0.05) under the measurement protocol in Section V-A4. Pre-transfer denotes effective results whose selected rules come from candidates already available in the target scenario before cross-scenario construction. Post-transfer denotes effective results whose selected rules come from target-scenario candidates constructed using cross-scenario example transfer or descriptions from other scenarios. Has doc info denotes effective results whose sources contain external documentation information. x86 64 reports source architecture provenance from the selected strategy cluster. Documentation information provides an important supplement for effective optimization results. Overall, 840 of 3831 effective results contain documentation information, accounting for 21.93%. C/C++ has the largest proportion, at 45.73%. Because the current external documentation information only covers C/C++-side documentation, the lower Has doc info proportions for Python and Rust are expected. This is notable because documentation inputs are much smaller than commitderived inputs, yet they account for nearly half of effective C/C++ results. Even without Python or Rust documentation inputs, documentation information appears in 8.06% and 8.62% of their effective results, suggesting that it may also contribute through cross-scenario target-candidate construction. Post-transfer target-scenario candidates. Cross-scenario example transfer also contributes many effective optimization results through target-candidate construction. Overall, 55.47% of effective results come from post-transfer target-scenario candidates, exceeding the 44.53% from pre-transfer candidates. This contribution is particularly clear in Python and Rust, where post-transfer rules account for 75.53% and 90.91% of effective results, respectively. This shows that MoST does not depend only on candidates already available in the target scenario, but also benefits from additional optimization knowledge introduced from other scenarios. Answer to RQ5. Among MoST’s effective optimization results, documentation information appears in 21.93% overall and 45.73% for C/C++, while post-transfer target-scenario candidates account for 55.47%. VI. T HREATS TO VALIDITY The main threats come from data leakage, benchmark and model choices, construct metrics, and implementation. We exclude each task’s exact commit or exact code source item and compare methods with the same LLM when possible, but LLM training data cannot be fully audited. EM and SemEqv measure reproduction of historical edits, while Max and Avg depend on available project workloads. C/C++ and

TABLE IV: Project-level performance results in the real-world project optimization experiment. Under each method, the four columns report Max, Avg, # ≥5%, and # ≥10%, respectively. Lang.

Repo

SemOpt

#Pts. Max

RocksDB Redis C/C++ gRPC LevelDB spdlog

2 6.66% 21 8.15% 16 37.25% 22 160.36% 45 20.00%

Click Flask Python Jinja2 Requests Scrapy

Rust

Rapier image regex sqlparser Tokio

Codex Spark

Avg #5 #10 2.38% 1 1.20% 3 5.56% 8 11.47% 10 3.33% 8

Avg

Codex 5.4 Mini

#5 #10

Eff.

Max

MoST

Avg #5 #10

0 -0.08% -0.40% 0 1.90% -0.20% 0 22.18% 3.81% 0 20.00% 0.91% 2 8.33% -0.46%

0 0 7 2 4

0 0 3 1 0

1.24% 0.83% 11.26% 1.99% 11.01% 0.40% 0.65% -0.89% 13.13% 0.12%

11 410.24% 148.46% 10 8 159.35% 20.51% 1 8 61.29% 32.20% 7 9 86.41% 42.46% 7 4 59.30% 53.44% 4

10 20.56% 10.12% 1 334.14% 28.12% 6 0.87% -0.68% 5 4.91% 2.92% 4 1.65% 0.28%

11 4 0 0 0

11 4 0 0 0

2 0 0 7 2

0 0 0 0 0

46.51% 12.13% 11 3.52% 1.51% 0 1.97% -0.15% 0 8.41% 5.05% 7 16.65% 6.74% 2

10 3.20% 36 79.61% 16 29.89% 8 8.49% 43 111.16%

0 24 5 0 8

Pre

Post

5.28% 0.85% 1.71% 8.80% 9.48%

2.27% 0.16% 0.18% 4.36% 1.73%

NA NA NA NA -0.06% -8.34% 0 23.83% -0.14% 1 1 77.21% 0.87% 6 74.43% 16.60% 8 7 12.70% 0.01% 1 3.36% 1.57% 0 0 4.30% 0.67% 0 40.16% 3.46% 13 13 37.25% 3.21% 11

Doc

x86 64

C/C++ 1404 1178 (83.90%) 226 (16.10%) 642 (45.73%) 642 (45.73%) Python 1998 489 (24.47%) 1509 (75.53%) 161 (8.06%) 0 (0.00%) Rust 429 39 (9.09%) 390 (90.91%) 37 (8.62%) 2 (0.47%) Total

Codex 5.4

Avg #5 #10

0 1 1 1 9

TABLE V: Source and cross-scenario example-transfer provenance of effective optimization results. Percentages use the Effective count in the same row as the denominator. Lang.

Max

0.84% 0.19% 8.01% 0.25% 6.39% 1.57% 5.13% -0.31% 12.50% 2.06%

0.71% 0 16.87% 25 8.79% 6 4.98% 5 4.57% 13

0 0 7 1 4

Max

3831 1706 (44.53%) 2125 (55.47%) 840 (21.93%) 644 (16.81%)

Python reuse SemOpt’s open-source code, benchmarks, and paper settings, while Rust is reimplemented following the SemOpt workflow. These choices improve comparability but bind the conclusions to this benchmark family and evaluation protocol. LLM nondeterminism, rule-generation failures, dataprocessing bugs, and scripted evaluation errors may also affect the results. VII. R ELATED W ORK Code optimization has long used rule-based, programanalysis, and search techniques, including compiler optimizations, memoization, misconfiguration repair, genetic optimization, CLion, and Clang-Tidy [5], [6], [25], [56]– [59]. These methods handle specific inefficiency patterns, but depend on expert-defined rules and are difficult to extend across languages and scenarios. Dedicated performance optimization models, such as VQ-VAE, Supersonic, and DeepDev-PERF [60]–[62], often underperform LLM-based methods [12]. Recent studies have explored LLM-based code optimization. PIE constructs an efficiency benchmark and finds that RAG outperforms direct prompting [11]; Gao et al. further study how example selection and ordering affect RAG [24]. We use RAG as a baseline to test whether raw retrieval can replace explicit strategy construction. RAPGen targets C# APIreplacement patches and mainly supports a single optimization strategy [12]. SemOpt extracts strategies from optimization commits and generates associated rules [15]; in contrast, MoST constructs strategies from heterogeneous data sources

0 8 2 0 7

0 -0.42% -1.47% 0 3 146.35% 13.86% 6 1 18.28% 2.55% 3 0 9.50% 4.85% 1 8 43.88% 1.84% 15

Max

0 21.18% 4 19.72% 1 67.55% 0 249.75% 1 31.95%

Avg #5 #10 12.01% 1 6.90% 13 16.69% 10 11.45% 6 5.88% 8

1 6 9 4 6

11 717.42% 258.17% 11 0 346.23% 44.55% 1 0 126.67% 49.30% 8 0 98.96% 43.75% 7 2 82.62% 70.83% 4

11 1 7 6 4

0 20.22% 5 384.42% 2 83.46% 0 23.81% 5 208.57%

1 35 11 1 18

4.44% 4 42.82% 35 23.17% 11 5.08% 5 35.42% 20

and transfers them across language and architecture scenarios. Cross-language code intelligence studies high-resource to low-resource code generation and multilingual code capabilities [63]–[65]; MoST instead transfers optimization strategies and regenerates target-scenario localization rules. Other systems are complementary: SBLLM searches candidate versions [13], SWIFTCODER fine-tunes for efficient code [66], PerfCodeGen uses execution feedback [14], PEACE studies project-level Python optimization through dependency-aware hybrid code editing [67], and POLO uses profiling, project context, and agent feedback for project-level C and C++ optimization [68]. These systems improve search, training, feedback, or project-level editing, whereas MoST focuses on strategy acquisition, abstraction, cross-scenario transfer, and rule-based localization. Recent studies have also used LLMs to synthesize static analysis checkers, including KNighter, AutoChecker, and MoCQ [21]–[23]. These studies show that high-precision checker synthesis still faces semantic boundaries, false positives, and false negatives. In MoST, Semgrep rules are only optimization-opportunity locators, not patch templates. Examples validate rule behavior, while final correctness is handled by LLM optimization, compilation and testing, and performance validation. Therefore, the rule stage can place more emphasis on recall. VIII. C ONCLUSION This paper presents MoST, an LLM-based code optimization framework that addresses two limitations of strategyguided optimization: reliance on historical commits and source-scenario-specific strategy formalization. MoST represents heterogeneous knowledge-source items as evidence objects, balances them through self-balanced weighted clustering, constructs target-scenario examples when needed, and generates validated static analysis rules to guide LLM optimization. Experiments on 351 historical optimization tasks and 15 real-world projects show that MoST improves optimization reproduction and project-level performance over SemOpt and Codex. Overall, the results indicate that integrating multiple

knowledge sources across scenarios can effectively expand strategy coverage for LLM-based code optimization. DATA AVAILABILITY Artifacts of this paper, including the implementation of MoST, all baseline implementations, and evaluation results, are available at https://figshare.com/s/f4499b791389351c72 17. R EFERENCES [1] ISO/IEC, “ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models,” 2011, accessed: 2026-07-01. [Online]. Available: https://www.iso.org/standard/35733.html [2] A. Nistor, T. Jiang, and L. Tan, “Discovering, reporting, and fixing performance bugs,” in 2013 10th Working Conference on Mining Software Repositories (MSR). IEEE, 2013, pp. 237–246. [3] M. Jovic, A. Adamoli, and M. Hauswirth, “Catch me if you can: performance bug detection in the wild,” in Proceedings of the 2011 ACM International Conference on Object Oriented Programming Systems Languages and Applications, 2011, pp. 155–170. [4] D. J. Dean, H. Nguyen, X. Gu, H. Zhang, J. Rhee, N. Arora, and G. Jiang, “PerfScope: Practical online server performance bug inference in production cloud computing infrastructures,” in Proceedings of the ACM Symposium on Cloud Computing, 2014, pp. 1–13. [5] W. M. McKeeman, “Peephole optimization,” Communications of the ACM, vol. 8, no. 7, pp. 443–444, 1965. [6] J. Cocke, “Global common subexpression elimination,” in Proceedings of a Symposium on Compiler Optimization, 1970, pp. 20–24. [7] E. Nijkamp, B. Pang, H. Hayashi, L. Tu, H. Wang, Y. Zhou, S. Savarese, and C. Xiong, “CodeGen: An open large language model for code with multi-turn program synthesis,” in International Conference on Learning Representations (ICLR), 2023, arXiv:2203.13474. [Online]. Available: https://openreview.net/forum?id=iaYcJKpY2B [8] R. Li, L. B. Allal, Y. Zi, N. Muennighoff, D. Kocetkov, C. Mou, M. Marone, C. Akiki, J. Li, J. Chim et al., “StarCoder: may the source be with you!” arXiv preprint arXiv:2305.06161, 2023. [Online]. Available: https://arxiv.org/abs/2305.06161 [9] D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y. Wu, Y. K. Li, F. Luo, Y. Xiong, and W. Liang, “DeepSeek-Coder: When the large language model meets programming – the rise of code intelligence,” arXiv preprint arXiv:2401.14196, 2024. [Online]. Available: https://arxiv.org/abs/2401.14196 [10] A. Fan, B. Gokkaya, M. Harman, M. Lyubarskiy, S. Sengupta, S. Yoo, and J. M. Zhang, “Large language models for software engineering: Survey and open problems,” in 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE). IEEE, 2023, pp. 31–53. [11] A. Shypula, A. Madaan, Y. Zeng, U. Alon, J. R. Gardner, Y. Yang, M. Hashemi, G. Neubig, P. Ranganathan, O. Bastani, and A. Yazdanbakhsh, “Learning performance-improving code edits,” in The Twelfth International Conference on Learning Representations (ICLR), 2024, arXiv:2302.07867. [Online]. Available: https://openrevi ew.net/forum?id=ix7rLVHXyY [12] S. Garg, R. Z. Moghaddam, and N. Sundaresan, “RAPGen: An approach for fixing code inefficiencies in zero-shot,” in 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2025, pp. 124–135, arXiv:2306.17077. [13] S. Gao, C. Gao, W. Gu, and M. R. Lyu, “Search-based LLMs for code optimization,” in 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), 2025, pp. 578–590, arXiv:2408.12159. [14] Y. Peng, A. D. Gotmare, M. R. Lyu, C. Xiong, S. Savarese, and D. Sahoo, “PerfCodeGen: Improving performance of LLM generated code with execution feedback,” in 2025 IEEE/ACM Second International Conference on AI Foundation Models and Software Engineering (Forge). IEEE, 2025, pp. 1–13. [15] Y. Zhao, Y.-A. Xiao, Q. Xiao, Z. Zhang, and Y. Xiong, “SemOpt: LLMdriven code optimization via rule-based analysis,” ACM Transactions on Software Engineering and Methodology, 2026. [16] Semgrep, “Semgrep,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/semgrep/semgrep

[17] Intel Corporation, “Intel® 64 and IA-32 Architectures Optimization Reference Manual Volume 1,” 2023, version 050; Accessed: 2026-0701. [Online]. Available: https://www.intel.com/content/www/us/en/cont ent-details/671488/intel-64-and-ia-32-architectures-optimization-refer ence-manual-volume-1.html [18] M. Ester, H.-P. Kriegel, J. Sander, and X. Xu, “A density-based algorithm for discovering clusters in large spatial databases with noise,” in Proceedings of the Second International Conference on Knowledge Discovery and Data Mining, 1996, pp. 226–231. [Online]. Available: https://aaai.org/papers/KDD96-037-a-density-based-algorithm-for-dis covering-clusters-in-large-spatial-databases-with-noise/ [19] J. Bergstra and Y. Bengio, “Random search for hyper-parameter optimization,” Journal of Machine Learning Research, vol. 13, no. 10, pp. 281–305, 2012. [Online]. Available: https://jmlr.org/papers/v13/be rgstra12a.html [20] J. Aitchison, “The statistical analysis of compositional data,” Journal of the Royal Statistical Society: Series B (Methodological), vol. 44, no. 2, pp. 139–160, 1982. [21] C. Yang, Z. Zhao, Z. Xie, H. Li, and L. Zhang, “KNighter: Transforming static analysis with LLM-synthesized checkers,” in Proceedings of the ACM SIGOPS 31st Symposium on Operating Systems Principles, 2025, pp. 655–669. [22] J. Liu, Y. Xie, J. Yan, J. Huang, J. Yan, and J. Zhang, “Write your own CodeChecker: An automated test-driven checker development approach with LLMs,” in IEEE/ACM International Conference on Software Engineering (ICSE), 2026, arXiv:2411.06796. [Online]. Available: https://arxiv.org/abs/2411.06796 [23] P. Li, S. Yao, J. S. Korich, C. Luo, J. Yu, Y. Cao, and J. Yang, “Neuro-symbolic static analysis with LLM-generated vulnerability patterns,” arXiv preprint arXiv:2504.16057, 2025. [Online]. Available: https://arxiv.org/abs/2504.16057 [24] S. Gao, X.-C. Wen, C. Gao, W. Wang, H. Zhang, and M. R. Lyu, “What makes good in-context demonstrations for code intelligence tasks with LLMs?” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2023, pp. 761–773. [25] LLVM Project, “Clang-Tidy,” 2026, accessed: 2026-07-01. [Online]. Available: https://clang.llvm.org/extra/clang-tidy/ [26] DeepSeek, “Models & Pricing: DeepSeek-V4-Pro,” 2026, accessed: 2026-07-01. [Online]. Available: https://api-docs.deepseek.com/quick s tart/pricing [27] OpenAI, “GPT-5.2 Model,” 2026, accessed: 2026-07-01. [Online]. Available: https://developers.openai.com/api/docs/models/gpt-5.2 [28] Facebook, “RocksDB,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/facebook/rocksdb [29] Redis, “Redis,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/redis/redis [30] gRPC Authors, “gRPC,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/grpc/grpc [31] Google, “LevelDB,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/google/leveldb [32] Gabi Melman, “spdlog,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/gabime/spdlog [33] Click Project, “Click Documentation,” 2026, accessed: 2026-07-01. [Online]. Available: https://click.palletsprojects.com/ [34] Flask Project, “Flask Documentation,” 2026, accessed: 2026-07-01. [Online]. Available: https://flask.palletsprojects.com/ [35] Jinja Project, “Jinja Documentation,” 2026, accessed: 2026-07-01. [Online]. Available: https://jinja.palletsprojects.com/ [36] Python Software Foundation, “Requests,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/psf/requests [37] Scrapy, “Scrapy,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/scrapy/scrapy [38] Dimforge, “Rapier,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/dimforge/rapier [39] image-rs, “image,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/image-rs/image [40] Rust Project Developers, “regex,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/rust-lang/regex [41] Apache Software Foundation, “datafusion-sqlparser-rs,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/apache/datafusion-s qlparser-rs [42] Tokio Contributors, “Tokio,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/tokio-rs/tokio [43] OpenAI, “Codex,” 2026, accessed: 2026-07-01. [Online]. Available: https://developers.openai.com/codex

[44] OpenAI Codex, “Codex Models: gpt-5.3-codex-spark,” 2026, accessed: 2026-07-01. [Online]. Available: https://developers.openai.com/codex/ models [45] OpenAI API, “GPT-5.4 mini Model,” 2026, accessed: 2026-07-01. [Online]. Available: https://developers.openai.com/api/docs/models/gp t-5.4-mini [46] OpenAI, “GPT-5.4 Model,” 2026, accessed: 2026-07-01. [Online]. Available: https://developers.openai.com/api/docs/models/gpt-5.4 [47] B. L. Welch, “The generalization of Student’s problem when several different population variances are involved,” Biometrika, vol. 34, no. 1-2, pp. 28–35, 1947. [48] J. Chen and J. Revels, “Robust benchmarking in noisy environments,” arXiv preprint arXiv:1608.04295, 2016. [Online]. Available: https: //arxiv.org/abs/1608.04295 [49] Z. Liu, S. Mada, and J. Regehr, “Minotaur: A SIMD-oriented synthesizing superoptimizer,” Proceedings of the ACM on Programming Languages, vol. 8, no. OOPSLA2, pp. 1561–1585, 2024. [50] J. Wen, Z. Chen, F. Sarro, and S. Wang, “Unveiling overlooked performance variance in serverless computing,” Empirical Software Engineering, vol. 30, no. 2, p. 59, 2025. [51] J. M. Fraile-Hernández and A. Peñas, “On measuring large language models performance with inferential statistics,” Information, vol. 16, no. 9, p. 817, 2025. [52] Linux Kernel Organization, “perf: Linux profiling with performance counters,” 2026, accessed: 2026-07-01. [Online]. Available: https: //perfwiki.github.io/ [53] Free Software Foundation, “Gcov,” 2026, accessed: 2026-07-01. [Online]. Available: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html [54] Python Software Foundation, “The Python profilers,” 2026, accessed: 2026-07-01. [Online]. Available: https://docs.python.org/3/library/profil e.html [55] pyutils, “line profiler,” 2026, accessed: 2026-07-01. [Online]. Available: https://github.com/pyutils/line profiler [56] L. Della Toffola, M. Pradel, and T. R. Gross, “Performance problems you can fix: A dynamic analysis of memoization opportunities,” ACM SIGPLAN Notices, vol. 50, no. 10, pp. 607–622, 2015. [57] R. Krishna, M. S. Iqbal, M. A. Javidian, B. Ray, and P. Jamshidi, “CADET: Debugging and fixing misconfigurations using counterfactual reasoning,” arXiv preprint arXiv:2010.06061, 2020. [Online]. Available: https://arxiv.org/abs/2010.06061 [58] R. Giavrimis, A. Butler, C. C. Petrescu, M. Basios, and S. K. Dash, “Genetic optimisation of C++ applications,” in 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2021, pp. 1180–1182.

[59] JetBrains, “CLion: A cross-platform IDE for C and C++,” 2026, accessed: 2026-07-01. [Online]. Available: https://www.jetbrains.com/ clion/ [60] B. Chen, D. Tarlow, K. Swersky, M. Maas, P. Heiber, A. Naik, M. Hashemi, and P. Ranganathan, “Learning to improve code efficiency,” arXiv preprint arXiv:2208.05297, 2022. [Online]. Available: https://arxiv.org/abs/2208.05297 [61] Z. Chen, S. Fang, and M. Monperrus, “Supersonic: Learning to generate source code optimizations in C/C++,” IEEE Transactions on Software Engineering, vol. 50, no. 11, pp. 2849–2864, 2024. [62] S. Garg, R. Z. Moghaddam, C. B. Clement, N. Sundaresan, and C. Wu, “DeepDev-PERF: a deep learning-based approach for improving software performance,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2022, pp. 948–958. [63] F. Cassano, J. Gouwar, F. Lucchetti, C. Schlesinger, A. Freeman, C. J. Anderson, M. Q. Feldman, M. Greenberg, A. Jangda, and A. Guha, “Knowledge transfer from high-resource to low-resource programming languages for code LLMs,” Proceedings of the ACM on Programming Languages, vol. 8, no. OOPSLA2, pp. 677–708, 2024. [64] A. Giagnorio, A. Martin-Lopez, and G. Bavota, “Enhancing code generation for low-resource languages: No silver bullet,” in 2025 IEEE/ACM 33rd International Conference on Program Comprehension (ICPC), 2025, pp. 478–488, arXiv:2501.19085. [65] S. Joel, J. J. W. Wu, and F. H. Fard, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, 2025. [66] D. Huang, G. Zeng, J. Dai, M. Luo, H. Weng, Y. Qing, H. Cui, Z. Guo, and J. M. Zhang, “EffiCoder: Enhancing code generation in large language models through efficiency-aware finetuning,” arXiv preprint arXiv:2410.10209, 2024. [Online]. Available: https://arxiv.org/abs/2410.10209 [67] X. Ren, J. Wan, Y. Peng, Z. Liu, M. Liang, D. Chen, W. Jiang, and Y. Li, “PEACE: Towards efficient project-level efficiency optimization via hybrid code editing,” in 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2025, pp. 1831– 1843. [68] J. Bai, R. Xu, S. Wu, D. Yang, J. Zhao, and G. Chen, “POLO: An LLM-powered project-level code performance optimization framework,” in Proceedings of the Thirty-Fourth International Joint Conference on Artificial Intelligence, IJCAI-25. International Joint Conferences on Artificial Intelligence Organization, 2025, pp. 7319–7328. [Online]. Available: https://doi.org/10.24963/ijcai.2025/814