Where Does the Performance Go? Understanding and Recovering Performance Regressions in C-to-Rust Translation

# Where Does the Performance Go? Understanding and Recovering Performance Regressions in C-to-Rust Translation
Source: [https://arxiv.org/html/2610.23044](https://arxiv.org/html/2610.23044)
Zhiqiang Yuan1, Chong Wang2, Zhenhao Zhou1, Junwei Liu1, and Xin Peng1Affiliation:1Department of Computer Science, Fudan University, ChinaAffiliation:2Nanyang Technological University, SingaporeAffiliation:\{zhiqiangyuan23, zhzhou24, jwliu24\}@m\.fudan\.edu\.cnAffiliation:chong\.wang@ntu\.edu\.sgAffiliation:pengxin@fudan\.edu\.cn

###### Abstract

Rust is increasingly adopted as a memory\-safe successor to C, and transpilers such asc2rustcan migrate entire C projects while preserving their behavior\. Preserving behavior, however, does not guarantee preserving performance\. We study this gap on 20 real\-world C projects and theirc2rusttranslations\. On the eight projects used for analysis, the translated Rust is more than 3% slower than the original C on 12 of 19 operations, by up to 62\.2%\. By comparing execution\-cost profiles, optimized LLVM IR, and compiler optimization remarks across each C–Rust pair, we trace these slowdowns to nine recurring performance issues, spanning residual runtime work, missed compiler optimizations, and C\-style source patterns, and derive an optimization direction for each\. We then presentPerfR, an LLM\-based approach that encodes these issues as reusable optimization rules to recover the performance of translated Rust\.PerfRprofiles each project to locate hot functions and matches them against rule\-specific patterns\. The LLM then checks each rule’s rewrite preconditions against the project context before rewriting, and a rewrite is kept only if it passes both functional and performance validation\. On 41 operations from twelve held\-out projects,PerfRpreserves C outputs on all tested workloads and speeds up 40 operations over thec2rusttranslations, 18 of which end up faster than the original C\. It outperforms the general\-purpose coding agentCodexon 31 of the 37 operations where both preserve C outputs, and outperforms its own variant without rule guidance on 34 of the 41 operations\.

## IIntroduction

C remains widely used in systems and performance\-critical software for its low\-level control, predictable performance, and minimal runtime overhead\[[1](https://arxiv.org/html/2610.23044#bib.bib35),[2](https://arxiv.org/html/2610.23044#bib.bib36)\]\. However, it is prone to memory\-safety errors such as buffer overflows and use\-after\-free, which remain a major source of systems\-software vulnerabilities\[[3](https://arxiv.org/html/2610.23044#bib.bib9),[4](https://arxiv.org/html/2610.23044#bib.bib44)\]\. Rust mitigates these risks through ownership and borrowing while retaining low\-level performance\[[5](https://arxiv.org/html/2610.23044#bib.bib10),[6](https://arxiv.org/html/2610.23044#bib.bib34)\], which has motivated efforts to migrate legacy C codebases to Rust, including Rust support in the Linux kernel\[[7](https://arxiv.org/html/2610.23044#bib.bib43)\]\. As manual migration is costly and error\-prone, automated C\-to\-Rust translation has become an active research area\[[8](https://arxiv.org/html/2610.23044#bib.bib41),[9](https://arxiv.org/html/2610.23044#bib.bib11),[10](https://arxiv.org/html/2610.23044#bib.bib24),[11](https://arxiv.org/html/2610.23044#bib.bib14)\]\.

Existing approaches fall into two families\. LLM\-based translators aim to produce safer, more idiomatic Rust and increasingly use program analysis and project\-level context to coordinate translations across components\[[12](https://arxiv.org/html/2610.23044#bib.bib15),[13](https://arxiv.org/html/2610.23044#bib.bib2),[14](https://arxiv.org/html/2610.23044#bib.bib18),[15](https://arxiv.org/html/2610.23044#bib.bib20),[16](https://arxiv.org/html/2610.23044#bib.bib19)\]\. However, their outputs are not guaranteed to preserve behavior, a problem that worsens as project scale grows\[[13](https://arxiv.org/html/2610.23044#bib.bib2),[17](https://arxiv.org/html/2610.23044#bib.bib30),[12](https://arxiv.org/html/2610.23044#bib.bib15),[14](https://arxiv.org/html/2610.23044#bib.bib18)\]\. Rule\-based transpilers such asc2rustinstead apply deterministic syntax\-directed rules that preserve source behavior, although their output retains C\-oriented representations and extensive unsafe code\[[8](https://arxiv.org/html/2610.23044#bib.bib41),[9](https://arxiv.org/html/2610.23044#bib.bib11),[18](https://arxiv.org/html/2610.23044#bib.bib26),[10](https://arxiv.org/html/2610.23044#bib.bib24),[19](https://arxiv.org/html/2610.23044#bib.bib23)\]\. Owing to this behavioral guarantee, rule\-based output has become a common starting point for practical migration: it has been used in industrial projects\[[20](https://arxiv.org/html/2610.23044#bib.bib61)\], and recent hybrid approaches refinec2rust\-generated Rust with LLM\-guided rewriting\[[21](https://arxiv.org/html/2610.23044#bib.bib12),[22](https://arxiv.org/html/2610.23044#bib.bib27),[23](https://arxiv.org/html/2610.23044#bib.bib21)\]\.

Recently, the performance of translated code has drawn attention\[[24](https://arxiv.org/html/2610.23044#bib.bib54),[25](https://arxiv.org/html/2610.23044#bib.bib28),[26](https://arxiv.org/html/2610.23044#bib.bib60)\]\. Behavioral preservation does not imply performance preservation, and regressions after migration can offset the benefits of Rust in performance\-critical software, where runtime efficiency is often a key reason for using C\. The concern is most direct in rule\-based output, which retains many C\-style code patterns\[[22](https://arxiv.org/html/2610.23044#bib.bib27),[18](https://arxiv.org/html/2610.23044#bib.bib26)\]that can introduce runtime overhead\. Xia et al\.\[[24](https://arxiv.org/html/2610.23044#bib.bib54)\]evaluatec2rust\-generated programs on a synthetic C corpus and identify Relooper\-induced code duplication as one source of runtime overhead, and RUSTY\[[27](https://arxiv.org/html/2610.23044#bib.bib55)\]avoids this control\-flow expansion through a specialized translation scheme\. General\-purpose optimizers such as SemOpt\[[28](https://arxiv.org/html/2610.23044#bib.bib56)\]and MoST\[[29](https://arxiv.org/html/2610.23044#bib.bib57)\]instead guide LLM\-based rewriting with reusable optimization knowledge\.

These efforts leave translation\-induced performance degradation only partially understood: existing measurements rely on synthetic programs and a single mechanism, while general optimization knowledge is not derived from the mechanisms that paired C–Rust analysis reveals\. Consequently, three questions remain open: \(1\)whether and how much performance degrades after C\-to\-Rust translation in real\-world projects; \(2\)which execution costs and code\-level mechanisms explain such degradation; and \(3\)whether recurring mechanisms can be distilled into reusable rules for automated performance recovery\.

To answer these questions, we conduct an empirical study of performance divergence in rule\-based C\-to\-Rust translation usingc2rust\[[8](https://arxiv.org/html/2610.23044#bib.bib41)\], a transpiler widely adopted in research\[[10](https://arxiv.org/html/2610.23044#bib.bib24),[30](https://arxiv.org/html/2610.23044#bib.bib22)\]and industry\[[20](https://arxiv.org/html/2610.23044#bib.bib61)\]\. Its deterministic translation enables controlled paired C–Rust performance comparison\. We construct a benchmark of 20 real\-world C projects and theirc2rusttranslations, using eight projects as the Study Dataset for empirical analysis and reserving the remaining twelve for evaluation\. We measure performance at the granularity of*operations*, each being a complete program task with checkable output that may span multiple API calls, such as compression or decompression inbzip2\. Across 19 operations in the Study Dataset, the translated Rust incurs more than3\.0%3\.0\\%runtime overhead over C on 12, eight of which exceed25\.0%25\.0\\%with a maximum of62\.2%62\.2\\%\. Execution\-cost decomposition reveals three recurring profiles: additional dynamic instructions, higher cycles per instruction, or both\. We trace these differences through optimized IR, compiler optimization remarks, and translated Rust source, identifying nine recurring performance issues\. These issues span residual runtime work, missed compiler transformations, and recurring source\-level patterns, each with a corresponding optimization direction\.

Building on these findings, we presentPerfR, a rule\-guided framework for recovering performance lost during C\-to\-Rust migration\.PerfRoperationalizes each identified performance issue as an optimization guidance that pairs its*Observed Pattern*with the corresponding*Optimization Direction*\. Given a C project,PerfRfirst obtains its unmodifiedc2rusttranslation \(denotedRawRust\), constructs operation\-level functional and performance workloads, and performs pre\-optimization normalization\.PerfRthen localizes rule\-specific issues in hot functions using optimized IR, compiler remarks, and Rust source\. For each pattern group, the LLM evaluates rewrite preconditions against project context and synthesizes a candidate rewrite using the applicable optimization directions\. Each candidate is accepted only if it preserves functionality and yields a net runtime improvement across the synthesized workloads\.

We evaluatePerfRon twelve held\-out projects againstRawRustandCodex, a general\-purpose coding agent, using C as the runtime reference\.PerfRpreserves C outputs on all 41 operations and reduces measured runtime relative toRawRuston 40\. After optimization, 18 operations run faster than C, including 10 by more than 3%\. Onminizchecksum computation, for example, overhead changes from\+16\.7%\+16\.7\\%forRawRustto−66\.0%\-66\.0\\%forPerfR\. Compared withCodex, which produces non\-equivalent outputs on four operations,PerfRachieves lower measured runtime on 31 of the 37 operations for which both preserve C outputs\. Finally, starting from the same refined baseline, rule\-guided optimization achieves lower runtime than unguided optimization on 34 of 41 operations\. This paper makes the following contributions:

- •Empirical characterization\.We construct a 20\-project benchmark and characterize performance divergence through runtime analysis, identifying nine recurring performance issues with corresponding optimization directions\.
- •Rule\-guided performance optimization\.We developPerfR, which turns the identified performance issues into reusable optimization rules and applies them through hotspot\-guided detection, precondition\-aware LLM rewriting, and functional and performance validation\.
- •Cross\-project evaluation\.We evaluatePerfRon twelve projects disjoint from rule derivation, compare its performance with C,RawRust, andCodex, and examine rule applicability and the effectiveness of the rule\-guided mechanism through an unguided ablation\.

## IIBackground

C and Rust Compilation Pipelines\.clangandrustcboth use LLVM for optimization and machine\-code generation, but their frontends can produce different LLVM IR from functionally equivalent C and Rust programs\[[31](https://arxiv.org/html/2610.23044#bib.bib1),[32](https://arxiv.org/html/2610.23044#bib.bib6)\]\. These differences arise from language\-specific semantics and program representations\. They affect both the work expressed in the IR and the information available to LLVM, potentially yielding machine code with different execution costs\. LLVM provides two complementary artifacts for examining these differences\.*Optimized IR*reveals what remains after optimization, while*optimization remarks*record selected transformations that LLVM performs or misses, with reasons when available, providing evidence about why optimization outcomes differ\. Together, they support compiler\-level analysis of C\-to\-Rust performance divergence\.

Execution Performance Decomposition\.For a fixed task and input, CPU execution time follows the performance equationTCPU=I×𝐶𝑃𝐼×TcycleT\_\{\\mathrm\{CPU\}\}=I\\times\\mathit\{CPI\}\\times T\_\{\\mathrm\{cycle\}\}, whereIIis the number of retired instructions,𝐶𝑃𝐼\\mathit\{CPI\}is the average number of cycles per instruction, andTcycleT\_\{\\mathrm\{cycle\}\}is the duration of one clock cycle\[[33](https://arxiv.org/html/2610.23044#bib.bib7)\]\. When implementations execute on the same processor under a fixed clock configuration, execution\-cost differences can arise from instruction count, CPI, or both\. Instruction count characterizes dynamic work, whereas CPI characterizes average per\-instruction cost\. Top\-Down Microarchitecture Analysis \(TMA\) complements this decomposition with a hierarchical view of processor utilization\. Its top\-level categories are Retiring, Frontend Bound, Bad Speculation, and Backend Bound, with Backend Bound further divided into Core Bound and Memory Bound\[[34](https://arxiv.org/html/2610.23044#bib.bib8)\]\. These categories help identify microarchitectural bottlenecks associated with CPI differences\.

## IIIEmpirical Study Setup

We study the runtime impact of mechanical C\-to\-Rust translation usingc2rust\[[8](https://arxiv.org/html/2610.23044#bib.bib41)\]and derive optimization rules for translated Rust\. We investigate the following research questions:RQ1 \(Performance Divergence\):How does mechanical C\-to\-Rust translation affect runtime performance?RQ2 \(Cost Decomposition\):What execution costs underlie the observed performance differences?RQ3 \(Performance Issue Patterns\):What recurring patterns characterize performance issues in translated Rust, and what are the potential optimization directions?

### III\-ABenchmark Construction

Project Selection\.We construct the initial candidate pool from prior project\-level C\-to\-Rust translation studies\[[10](https://arxiv.org/html/2610.23044#bib.bib24),[9](https://arxiv.org/html/2610.23044#bib.bib11),[35](https://arxiv.org/html/2610.23044#bib.bib25),[25](https://arxiv.org/html/2610.23044#bib.bib28),[13](https://arxiv.org/html/2610.23044#bib.bib2),[21](https://arxiv.org/html/2610.23044#bib.bib12),[36](https://arxiv.org/html/2610.23044#bib.bib5)\]\. After deduplication, a project is eligible if it \(i\) contains at least 1 KLoC of project\-owned C source and headers, excluding tests, examples, and dependencies; \(ii\) can be translated byc2rustinto a functionally equivalent crate; and \(iii\) supports a deterministic workload exercising a measurable hotspot in project\-owned code\. We exclude projects whose execution is dominated by I/O or external libraries\. These criteria yield 16 projects; to broaden external validity, we add four C libraries satisfying the same criteria:xxHash\[[37](https://arxiv.org/html/2610.23044#bib.bib46)\],lz4\[[38](https://arxiv.org/html/2610.23044#bib.bib47)\],miniz\[[39](https://arxiv.org/html/2610.23044#bib.bib48)\], andhttp\-parser\[[40](https://arxiv.org/html/2610.23044#bib.bib49)\]\. The resulting benchmark contains 20 projects ranging from 1 to 180 KLoC, partitioned into an eight\-project*Study Dataset*for empirical analysis and performance\-issue characterization and a disjoint twelve\-project*Evaluation Dataset*for approach evaluation\.

TABLE I:Projects and workloads in the Study and Evaluation Datasets\.ProjectKLoCOperationsWorkload Inputslibcsv1\.0Parsing; Field escaping67 MiB CSV‡; 10K escaped fields‡libogg2\.9Stream encoding; Decoding300K / 30K packets \(1 KiB each\)‡xxHash3\.9XXH64; XXH3; XXH32 hashing64 KiB buffer‡libzahl5\.7Multiplication; Long division; Modular exponentiation4,096\-bit factors‡; 8,192/4,096\-bit dividend/divisor‡; 4,096\-bit base/modulus and 256\-bit exponent‡bzip25\.9Compression; DecompressionSilesia files†\(∼\{\\sim\}100 MiB\); Derived\.bz2files‡\(∼\{\\sim\}24 MiB\)binn6\.4Serialization; Deserialization100K\-elementint32list‡json\-c6\.9Parsing; SerializationCanada/CITM/Twitter JSON†\(4\.4 MiB\)heman13\.8Distance field; Lighting; Terrain generationGrayscale grids†\(102421024^\{2\}/204822048^\{2\};2562256^\{2\}\); Terrain‡\(5122512^\{2\}\)libopenaptx1\.3aptX encoding; aptX decoding; Stream recoveryPCM signal \(2 MiB\)‡; Derived aptX/aptX\-HD streams‡http\-parser2\.5Request, response, incremental, and URL parsingRequest, response streams \(18\.6K\)‡; 32K URLs‡fzy2\.6Fuzzy scoring; Choice\-list search; Candidate\-list parsing11K repository paths†; Six queries‡zopfli2\.9DEFLATE compressionSilesia slices†\(48–96 KiB\)lil3\.6Script execution; Embedding API24 upstream scripts†; Fixed API inputs‡miniz4\.2Compression; Decompression; Streaming; Checksums; ZIP processingSilesia files†\(48 KiB–9\.7 MiB\); Derived zlib/DEFLATE streams and ZIP archives‡lz45\.9Compression; Decompression; Streaming; Dictionary modesSilesia files†and stress inputs‡\(48 KiB–9\.7 MiB\); Derived LZ4 streams‡lodepng5\.9PNG decoding; PNG encoding; Color conversion; zlib processing; Chunk processingPNG images†and derived color variants‡\(1\.3–1\.8 Mpx\); RGBA buffers‡libqrencode6\.7QR encoding; Micro\-QR encoding; Structured appendURL and text inputs†; Identifier payloads‡\(58 total\)optipng9\.2PNG optimization; Format conversionPNG images†; Converted variants‡\(13 KiB–3\.8 MiB\)brotli16\.0Compression; Decompression; Streaming; Dictionary modesSilesia files†\(96 KiB–9\.7 MiB\); 1 MiB incompressible data‡; Derived Brotli streams‡libxml2180\.0Parsing; Validation; XPath Evaluation; Serialization; Dictionary/URI/string utilitiesUpstream XML and HTML documents \(105\) and schemas \(154\)†; Fixed utility inputs‡
The upper/lower blocks comprise the Study/Evaluation datasets \(8/12 projects\);†\\dagger: existing corpora tests;‡\\ddagger: study\-generated inputs\.

Operation Selection\.We define an*operation*as a semantically complete end\-to\-end task that exercises a coherent unit of functionality, may span multiple APIs, and yields a checkable output\. Operations provide a suitable granularity for performance comparison: project\-level measurements are too coarse to distinguish functional paths, whereas API\-level measurements are too fine\-grained to represent complete functional tasks\. We select an operation if it \(i\) represents core functionality, \(ii\) exercises a distinct performance\-relevant implementation path, and \(iii\) can be executed on both C and thec2rusttranslation with outputs checked for equivalence\. Multiple operations from the same project are retained only when they exercise distinct implementations\. For example, we include both compression and decompression inbzip2because exercise distinct implementation paths, and XXH64, XXH3, and XXH32 inxxHashbecause they implement distinct hashing algorithms\.

Workload Inputs\.For each benchmark operation, we prefer established corpora or upstream\-provided inputs, such as the Silesia corpus\[[41](https://arxiv.org/html/2610.23044#bib.bib3)\]and the Native JSON Benchmark\[[42](https://arxiv.org/html/2610.23044#bib.bib4)\]\. When suitable upstream inputs are unavailable, we generate inputs deterministically from fixed parameters so that the C implementation and itsc2rusttranslation process identical data\. For input\-sensitive operations, we use multiple sizes or formats\. For inverse operations, we generate the corresponding forward output once with the C reference and reuse it unchanged for both implementations\. Overall, the workloads span upstream, generated, and derived inputs across multiple sizes and formats, while preserving identical inputs for each C–Rust comparison\. The selected workloads achieve 73\.0–100\.0% coverage of reachable functions in each project\.

### III\-BExperimental Settings

Build Configuration\.We usec2rust0\.22\.1 to translate the C project into the corresponding Rust\. For all comparisons, we compile C withclang\-17\(17\.0\.6\) and all Rust withrustc1\.77\.0\-nightly \(2024\-01\-15\), both using LLVM 17\.0\.6\. C uses\-O3 \-flto; Rust usesopt\-level=3, fat LTO, one codegen unit, andpanic=abort\. Both sides target the native CPU with AVX\-512 disabled to ensure ISA parity; binary inspection confirms that neither emits AVX\-512 instructions\.

Execution Environment\.Measurements run on an Intel Core i9\-10980XE CPU with 18 physical cores\. To reduce system noise, we pin each run to an isolated physical core\. We use theperformancegovernor with turbo boost disabled to stabilize frequency, and Intel Resource Director Technology to reduce memory\-bandwidth interference\.

Measurement Protocol\.For each operation, corresponding C and Rust drivers invoke the respective implementations on the same workload input, and we measure them in pairs to obtain stable and directly comparable runtime estimates\. When a single execution is too short for reliable timing, we use a fixed number of in\-process repetitions to reach a minimum measurement duration, with the same repetition count for C and Rust\. After warm\-up, we collect paired measurements while alternating the C–Rust execution order across pairs to reduce temporal drift and order effects\. We assess stability using the coefficient of variation \(CV\) of the pairwise Rust\-to\-C runtime ratios and repeat any unstable batch\. For accepted batches, we remove ratio outliers using Tukey’s1\.5×1\.5\\timesIQR rule\[[43](https://arxiv.org/html/2610.23044#bib.bib50)\]and report median runtimes\. A pilot study on representative workloads showed that runtime estimates stabilized with a minimum measurement duration of 500 ms, five warm\-up rounds, and 30 measurement pairs; we therefore use these settings throughout, consider a batch unstable when CV exceeds 3%, and allow at most two retries\.

Evaluation Metrics\.We measure runtime using end\-to\-end wall\-clock time\. LettCt\_\{C\}andtRt\_\{R\}denote the median execution times of C and Rust for the same operation and input\. Relative runtime overhead is𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑=\(tR−tC\)/tC\\mathit\{overhead\}=\(t\_\{R\}\-t\_\{C\}\)/t\_\{C\}, where positive and negative values indicate slowdowns and speedups, respectively\. To explain runtime differences, we decomposeTCPUT\_\{\\mathrm\{CPU\}\}into dynamic work and per\-instruction cost usingRinst=IR/ICR\_\{\\mathrm\{inst\}\}=I\_\{R\}/I\_\{C\}andRCPI=𝐶𝑃𝐼R/𝐶𝑃𝐼CR\_\{\\mathrm\{CPI\}\}=\\mathit\{CPI\}\_\{R\}/\\mathit\{CPI\}\_\{C\}, respectively\.

### III\-CExperimental Procedure

RQ1: Performance Divergence\.Using the settings in Section[III\-B](https://arxiv.org/html/2610.23044#S3.SS2), we compare C with itsc2rusttranslation for each operation–input pair and compute runtime overhead\.

RQ2: Cost Decomposition\.Separately from runtime measurement, we measure retired instructions and CPU cycles over three runs, using their medians to computeRinstR\_\{\\mathrm\{inst\}\}andRCPIR\_\{\\mathrm\{CPI\}\}\. For operations with materially higher CPI \(RCPI≥1\.05R\_\{\\mathrm\{CPI\}\}\\geq 1\.05\), we further apply TMA to identify the microarchitectural sources and report the correspondingc2rusttranslation and C differences in cycles per instruction\.

RQ3: Performance Issue Patterns\.To characterize recurring code\-level performance issues, we focus on operations for whichc2rustincurs more than 3% runtime overhead over C\. For each operation, we useperfto rank project\-owned functions by sampled\-cycle share and select the hottest functions accounting for at least 80% of sampled cycles; subsequent analysis is restricted to these functions\. We examine the selected functions using three complementary evidence sources: whole\-program optimized IR, compiler optimization remarks, and translated Rust source\.

*Optimized IR\.*We compare whole\-program optimized IR of C and itsc2rusttranslation\. We identify sites where translated Rust retains cost\-bearing operations absent from C, such as bounds\-check failure paths or saturating conversions\. We also consider optimizer\-relevant information in C but missing from Rust when its absence is accompanied by additional memory operations;

*Optimization Remarks\.*We compare source\-mapped optimization remarks for C and itsc2rusttranslation\. We retain cases where LLVM applies a transformation to C but reports a blocking condition for the corresponding translated Rust code, and discard cases where the reported difference does not persist in the optimized IR;

*Translated Rust Source\.*We use*The Rust Performance Book*\[[44](https://arxiv.org/html/2610.23044#bib.bib62)\]as an inspection guide rather than a predefined taxonomy of performance issues\. We derive concrete inspection criteria from relevant recommendations and apply them to hot translated Rust code\. For example, guidance on heap allocation motivates inspection of repeated allocation and non\-amortized buffer growth\. We also examine recurring structures such as loop\-invariant dispatch, pointer–length memory operations, raw\-pointer traversal, and element\-wise processing\.

We analyze the evidence in three steps\. First, we record each performance\-relevant candidate instance with its source region in the translated Rust, its manifestation in IR, compiler remarks, or source code, and its cost mechanism\. Evidence from multiple representations referring to the same source construct and mechanism is merged\. We then discard candidates whose code is not exercised by the workload \(58\) or belongs to the benchmark harness rather than the project \(14\), whose evidence does not support the stated mechanism \(48\), or whose C–Rust difference disappears in optimized IR \(15\)\. Of 404 candidates, 269 are retained as*instances*\. Second, we group instances that share an underlying performance mechanism and admit a common remediation strategy\. We retain only groups supported by at least three instances; each retained group defines a*Performance Issue*\. This yields nine issues covering 268 of the 269 instances\. The remaining instance concerns a state variable introduced byc2rustto emulategoto; observed in only one function, it falls below the support threshold\. Third, for each retained issue, we abstract its recurring manifestations into an*Observed Pattern*and derive an*Optimization Direction*targeting the underlying mechanism\. For issues identified through IR or compiler remarks, we use paired C–Rust evidence to determine how to eliminate extra work absent from C or restore optimizations realized in C\. For source\-level issues, we map the underlying mechanism to a recommendation in*The Rust Performance Book*\[[44](https://arxiv.org/html/2610.23044#bib.bib62)\], such as reusing a buffer across calls rather than allocating and freeing it on every call\.

TABLE II:Runtime overhead \(Δ\\Delta\) afterc2rusttranslation; positive values indicate slowdown over C\.ProjectOperation \(Δ\\Delta\)ProjectOperation \(Δ\\Delta\)ProjectOperation \(Δ\\Delta\)libcsvParsing\+35\.1%\+35\.1\\%xxHashXXH64−0\.3%\-0\.3\\%binnSerialization\+40\.9%\+40\.9\\%Field escaping\+8\.3%\+8\.3\\%XXH3\+33\.1%\+33\.1\\%Deserialization\+27\.9%\+27\.9\\%liboggStream encoding\+2\.2%\+2\.2\\%XXH32\+62\.2%\+62\.2\\%json\-cParsing\+1\.9%\+1\.9\\%Decoding\+0\.2%\+0\.2\\%libzahlMultiplication\+37\.3%\+37\.3\\%Serialization\+2\.8%\+2\.8\\%bzip2Compression\+1\.4%\+1\.4\\%Long division−0\.6%\-0\.6\\%hemanDistance\-field\+27\.6%\+27\.6\\%Decompression\+15\.5%\+15\.5\\%Modular exp\.\+10\.2%\+10\.2\\%Lighting\+29\.5%\+29\.5\\%Terrain generation\+19\.0%\+19\.0\\%

## IVStudy Results

### IV\-ARQ1: Performance Divergence

Table[II](https://arxiv.org/html/2610.23044#S3.T2)reports runtime overhead relative to C afterc2rusttranslation across 19 operations\. Overhead ranges from−0\.6%\-0\.6\\%forlibzahllong division to\+62\.2%\+62\.2\\%forxxHashXXH32\. Seven operations remain within±3%\\pm 3\\%of C, whereas twelve are more than3%3\\%slower, including eight with overhead above25%25\\%\. Performance divergence also varies substantially within the same project\. ForxxHash, the same 64 KiB input yields overheads of−0\.3%\-0\.3\\%for XXH64,\+33\.1%\+33\.1\\%for XXH3, and\+62\.2%\+62\.2\\%for XXH32\. Similar contrasts appear inlibzahl, where long division incurs−0\.6%\-0\.6\\%overhead but multiplication incurs\+37\.3%\+37\.3\\%, and inbzip2, where compression incurs\+1\.4%\+1\.4\\%but decompression incurs\+15\.5%\+15\.5\\%\. These results indicate that the performance impact of C\-to\-Rust translation is highly operation\-dependent, even within the same project\.

Finding 1:Mechanical translation can substantially degrade runtime performance, though the extent varies by operation\.

### IV\-BRQ2: Cost Decomposition

TABLE III:Execution\-cost decomposition of the 12 operations with runtime overhead above3%3\\%\.Costdenotes increased dynamic work \(Work\), increased CPI only \(CPI\), or both \(Both\)\.CostProjectOperation𝑹𝐢𝐧𝐬𝐭\\boldsymbol\{R\_\{\\mathrm\{inst\}\}\}𝑹𝐂𝐏𝐈\\boldsymbol\{R\_\{\\mathrm\{CPI\}\}\}CostProjectOperation𝑹𝐢𝐧𝐬𝐭\\boldsymbol\{R\_\{\\mathrm\{inst\}\}\}𝑹𝐂𝐏𝐈\\boldsymbol\{R\_\{\\mathrm\{CPI\}\}\}WorkbinnSerialization1\.5301\.5300\.9210\.921CPIhemanLighting0\.9350\.9351\.3911\.391WorkDeserialization1\.4501\.4500\.8990\.899CPIlibcsvField escaping0\.9940\.9941\.0891\.089Workbzip2Decompression1\.3481\.3480\.8600\.860BothlibcsvParsing1\.2671\.2671\.0671\.067WorkhemanTerrain generation1\.2261\.2260\.9700\.970BothxxHashXXH31\.2701\.2701\.0521\.052WorklibzahlModular exponentiation1\.1231\.1230\.9800\.980BothhemanDistance\-field pipeline1\.0781\.0781\.1861\.186CPIxxHashXXH320\.4750\.4753\.4173\.417BothlibzahlMultiplication1\.2311\.2311\.1131\.113The 12 regressions separate into three execution\-cost profiles \(Table[III](https://arxiv.org/html/2610.23044#S4.T3)\)\. Five areWorkcases, where instruction inflation is partially offset by lower CPI; three areCPIcases, where CPI increases without instruction inflation; and four areBothcases, where instruction inflation and higher CPI compound\. Overall, instruction inflation occurs in nine of 12 regressions, CPI degradation in seven, and both in four\.bzip2decompression illustrates the first profile: it executes 34\.8% more instructions but at 14\.0% lower CPI, partially offsetting the additional work\. In contrast, thehemandistance\-field pipeline executes 7\.8% more instructions at 18\.6% higher CPI, compounding the two costs\.

For operations with materially higher CPI, TMA further localizes the increase to microarchitectural bottlenecks\. In thehemandistance\-field pipeline, Memory Bound contributes \+0\.13 cycles per instruction to the CPI increase afterc2rusttranslation\. ForxxHashXXH32, Memory Bound and Core Bound contribute \+0\.50 and \+0\.48 cycles per instruction, respectively\. Thus, CPI degradation does not arise from a single recurring bottleneck; its source varies across operations\.

Finding 2:Translation overhead stems from both additional dynamic work and higher per\-instruction cost, with instruction inflation emerging as the more common source\.

### IV\-CRQ3: Performance Issue Patterns

TABLE IV:Recurring performance issues and optimization directions identified in the Study Dataset\.Performance IssueDefinitionObserved PatternOptimization DirectionResidual Bounds ChecksBounds checks remain even when established index\-range invariants prove them unnecessary\.Loop invariants establish valid indices, but optimized Rust IR retains checks leading topanic\_bounds\_checkthat are absent from C IR\.Express valid iteration bounds through slices or iterators to expose index–length relationships and enable elimination of redundant checks\.Redundant Conversion SaturationSaturating float\-to\-integer conversions remain even when range invariants prove them unnecessary\.Optimized Rust IR usesllvm\.fptosi\.satorllvm\.fptoui\.satfor range\-bounded operands, whereas C IR usesfptosiorfptoui\.Avoid unnecessary saturation withto\_int\_uncheckedfor finite operands whose values, truncated toward zero, fit the target integer type\.Missed Loop VectorizationLoop vectorization achieved in C is lost after translation to Rust\.LLVM vectorizes a C loop but leaves its Rust counterpart scalar; remarks identify control\-flow, call, or memory\-dependence barriers\.Restructure blocking control flow or calls, or expose valid dependence information to enable loop vectorization\.Missed Hot\-Callee InliningHot calls inlined in C remain uninlined in translated Rust\.A hot call is inlined in C but retained in Rust; IR comparison reveals missing inlining attributes, or remarks report excessive cost\.Restore missing inlining annotations or simplify the callee to reduce its estimated inlining cost\.Repeated Invariant DispatchLoops dispatch on callbacks or mode values that remain invariant across iterations\.A loop repeatedly invokes an invariant callback,e\.g\.,cb\.expect\(\.\.\.\)\(args\), or branches on an invariant mode\.Resolve loop\-invariant callback or mode dispatch once before the loop, then execute a specialized loop for the selected target or mode\.Inefficient Buffer ManagementRepeated allocation or fixed\-increment growth incurs avoidable heap\-allocation overhead\.An internal buffer is repeatedly allocated and freed, or grows by fixed increments throughrealloc\.Reuse buffers to reduce allocations; reserve capacity upfront or use geometric growth to reduce reallocations\.Byte\-Oriented Memory OperationsByte\-oriented processing fails to exploit known type, width, or length information\.Typed values usememcpy/memsetor hand\-written byte\-order helpers; known string lengths are recomputed withstrlen\.Express copy and fill through slices, use fixed\-width byte\-order conversions, and reuse known string lengths\.Scalar Element\-Wise ProcessingElement\-wise processing leaves parallel or block\-wise computation opportunities unused\.A loop processes adjacent elements individually \(e\.g\.,out\[i\] = f\(in\[i\]\)\), or individually updates or compares elements\.Process independent elements in groups, or replace per\-element updates and comparisons with equivalent block\-wise operations\.Obscured Memory Access PropertiesInsufficiently exposed access relationships and invariants inhibit load elimination or hoisting\.A loop accesses buffers through raw pointers \(e\.g\.,ptr\.add\(i\)\), with separately tracked bounds and implicit aliasing relationships\.Recover valid&\[T\]/&mut \[T\]views to expose access properties to LLVM, or hoist loop\-invariant loads\.Table[IV](https://arxiv.org/html/2610.23044#S4.T4)reports the nine recurring performance issues identified by our analysis, organized by their primary manifestation: residual runtime work \(two\), missed compiler transformations \(two\), and source\-level performance issues \(five\)\. These categories are not mutually exclusive, as residual operations or retained calls may also inhibit downstream compiler transformations\.

Residual Runtime Work\.Optimized IR reveals two recurring forms of residual work in translated Rust:*Residual Bounds Checks*and*Redundant Conversion Saturation*\.*Residual Bounds Checks*persist despite provably valid access ranges\. InBZ2\_decompress, a nested traversal writes\(\*s\)\.inUse\[\(i \* 16 \+ j\) as usize\], wherei < 16andj < 16guarantee an index below 256\. Yet the Rust IR retains a comparison against 256 and a branch topanic\_bounds\_check, while the corresponding C IR has no such failure path\. The translated state\-machine control flow prevents LLVM from recovering this range invariant\. Expressing the traversal over a bounded slice makes the valid extent explicit and enables the redundant check to be eliminated\.*Redundant Conversion Saturation*persists when operand ranges rule out saturation but the Rust IR retains saturating float\-to\-integer conversions\. Inheman, seven such conversions originate fromfastFloorafter inlining intoheman\_internal\_generate\_island\_noise\. The Rust IR usesllvm\.fptosi\.satorllvm\.fptoui\.sat, whereas the corresponding C IR uses directfptosiorfptoui\. The operands are finite grid coordinates whose truncated values remain within the target integer range\. Once these conditions are established,to\_int\_uncheckedeliminates the redundant saturation\.

Missed Compiler Transformations\.Paired C–Rust compiler remarks reveal two recurring missed transformations in translated Rust:*Missed Loop Vectorization*and*Missed Hot\-Callee Inlining*\. The*Missed Loop Vectorization*issue occurs when LLVM vectorizes a C loop but leaves its translated Rust counterpart scalar\. Inbzip2, five hot decode loops exhibit this divergence\. In a representative move\-to\-front loop that shiftsmtfaentries, each array access carries a bounds check that adds a loop exit, and LLVM reports that it could not determine the number of loop iterations\. Expressing the shift as a bounded slice operation can remove these checks and enable vectorization\. The*Missed Hot\-Callee Inlining*issue occurs when a hot call inlined in C remains uninlined in translated Rust because of missing inlining attributes or excessive estimated callee cost\. InxxHash, the C implementation forcesXXH3\_accumulate\_512\_scalarto inline, whereas its translated Rust counterpart lacks the corresponding annotation and retains the call inside the hot stripe\-processing loop\. Restoring the missing inlining annotation can eliminate this barrier\.

Recurring Source\-Level Patterns\.Source inspection identifies five patterns in translated Rust code:*Repeated Invariant Dispatch*,*Inefficient Buffer Management*,*Byte\-Oriented Memory Operations*,*Scalar Element\-Wise Processing*, and*Obscured Memory Access Properties*\. Unlike residual runtime work and missed compiler transformations, these patterns are characterized primarily by recurring source structures and their associated cost mechanisms\. For example,*Inefficient Buffer Management*occurs inlibzahl, wherezmul\_llcreates and releases four temporary integers at every recursion level, resizing their storage throughlibzahl\_reallocwhen needed\. Reusing preallocated scratch storage across recursive calls avoids this repeated allocation and resizing overhead\.

The*Obscured Memory Access Properties*issue arises when raw\-pointer accesses leave bounds and aliasing relationships implicit, limiting LLVM’s ability to eliminate redundant loads\. Inlibzahl,zrshtraverses limb arrays through raw\-pointer accesses such as\*ptr\.offset\(i\)\. The optimized Rust IR contains 73 static load instructions, compared with 24 in C, and lacks the\!tbaametadata present in the C IR\. Consistently, GVN emits 46 missed\-optimization remarks for Rust, versus 16 for C, frequently citing potentially aliasing writes as barriers to load elimination\. Together, these observations suggest that obscured access relationships lead to conservative memory\-dependence assumptions that inhibit load reuse\. Recovering valid&\[T\]/&mut \[T\]views can expose these properties to LLVM and enable load elimination\.

Finding 3:We identify nine recurring performance issues in translated Rust, spanning residual work, missed compiler transformations, and source\-level patterns, with optimization directions\.

## VApproach

![Refer to caption](https://arxiv.org/html/2610.23044v1/pics/pipline.png)Fig\. 1:Workflow ofPerfRThe performance issues derived in §[IV\-C](https://arxiv.org/html/2610.23044#S4.SS3)provide reusable guidance for recovering translation\-induced performance loss\. Applying this guidance to a new project requires localizing performance\-critical code and identifying applicable rules\. We therefore presentPerfR, a rule\-guided framework for recovering performance lost during C\-to\-Rust migration\. Starting from a C project,PerfRobtainsRawRustwithc2rust, synthesizes workloads, and performs pre\-optimization normalization \(Figure[1](https://arxiv.org/html/2610.23044#S5.F1)\)\.PerfRthen localizes hot functions, identifies applicable optimization rules, and uses project context to guide precondition\-aware LLM rewrites\. Each rewrite is accepted only if it preserves functionality and improves performance\.

### V\-AWorkload Synthesis

Project\-level optimization requires executable workloads to locate runtime hotspots and evaluate candidate rewrites\. To capture end\-to\-end behavior and cost,PerfRorganizes these workloads around operations that compose related APIs into complete tasks with checkable outputs\. Starting fromRawRust,PerfRsynthesizes executable operations and harnesses and refines them using coverage feedback\. This shared execution basis supports two complementary workload types: functional workloads provide diverse inputs for regression testing, while performance workloads provide sufficiently long executions for hotspot localization and performance validation\. These internal workloads are independent of the benchmark workloads used for final evaluation\.

Operation and Harness Synthesis\.PerfRfirst extracts the public API ofRawRust, includingpubfunctions and structs together with their module paths, and provides this information to the LLM\. The LLM plans a bounded set of end\-to\-end operations, each representing a distinct functional task and identifying the API elements needed to realize it\. Planning prioritizes core functionality and broad public\-function coverage across the operation set\.

The planned operations, however, are not directly executable\. For each operation, the LLM uses the associated API signatures to generate an executable*harness*and a small set of distinct seed inputs\. The harness invokes the relevant APIs for each seed and produces an observable output\.PerfRcompiles and repeatedly executes the harness to check successful execution and output determinism\. It also checks for output variation across distinct seeds to reject degenerate harnesses that ignore their inputs\. When a check fails, the corresponding diagnostic feedback is returned to the LLM for revision\[[13](https://arxiv.org/html/2610.23044#bib.bib2),[45](https://arxiv.org/html/2610.23044#bib.bib32)\]\. This process continues within a fixed repair budget, and an operation is retained only when its harness passes all checks\.

Executability alone, however, does not ensure broad coverage of the public API\.PerfRtherefore measures public\-function coverage across the retained operations using an instrumented build and their seed inputs\. If coverage remains below the target, the uncovered functions and their signatures are provided to the LLM, which extends existing operations or introduces new ones\. The harnesses and seed inputs are then generated and validated through the same process before coverage is recomputed\. This feedback loop continues until the coverage target is reached or the refinement budget is exhausted, yielding the final operation set and validated harnesses\.

Functional Workload Synthesis\.The validated harnesses establish operation executability, but their small seed sets provide limited behavioral diversity for regression testing\.PerfRtherefore fuzzes the seeds of each retained operation to generate a broader input corpus\. Each generated input is executed repeatedly on the initialRawRust\. Inputs that fail or produce nondeterministic outputs are discarded, while stable output digests are recorded as regression references\. The retained inputs, their reference digests, and the corresponding harness together form the*functional workload*used to validate subsequent rewrites\.

Performance Workload Synthesis\.Functional workloads prioritize input diversity, but individual executions may be too short for reliable performance measurement\.PerfRtherefore constructs a separate performance input for each operation by scaling a semantically meaningful input dimension, such as record count, data size, or image dimensions\. For operations that consume derived formats,PerfRscales the source data and invokes the corresponding producer operation to construct a valid input\. If a single execution remains too short for stable timing,PerfRcalibrates a fixed number of in\-process repetitions to reach a minimum measurement duration\. The harness, performance input, and repetition count together define a*performance workload*used for hotspot localization and performance validation\. The operation budget, coverage target, refinement budget, and timing parameters are specified in the experimental setup\.

### V\-BPre\-optimization Normalization

Given a C project,c2rustyieldsRawRust, which preserves the behavior of the C program\. However,RawRustretains C\-oriented representations, including duplicated definitions, internalextern ‘‘C’’boundaries, and pervasive raw\-pointer accesses\. Although these representations are not the performance issues identified in §[IV\-C](https://arxiv.org/html/2610.23044#S4.SS3), they hinder project\-wide analysis and coordinated rewriting while obscuring optimization\-relevant program properties\.PerfRperforms a preparatory refinement that consolidates shared definitions and refines internal ABI, pointer, and safety boundaries\. Each refinement is validated against §[V\-A](https://arxiv.org/html/2610.23044#S5.SS1)functional workloads; failing changes are reverted\.

#### V\-B1Definition Consolidation

Declarations from shared C headers may appear as duplicate definitions across translated Rust modules\.PerfRcollects top\-level items, including nominal types, type aliases, constants, statics, and functions, and groups them by source provenance\. Definitions are compared after ignoring comments and formatting whitespace; attributes, declared types, and item bodies remain part of the comparison\. Items originating from the same C declaration with identical normalized definitions form candidate groups\. Static definitions remain separate to preserve storage identity\. Function consolidation additionally requires consistent resolved dependencies and compatible linkage semantics\. Eligible groups are processed in dependency order\. For each group,PerfRretains one canonical definition in a shared module and replaces the remaining copies with imports\.

#### V\-B2Boundary Refinement

Internal ABI Recovery\.After definition consolidation,PerfRexamines each project\-definedextern "C"function to determine whether the C ABI remains necessary\. The boundary is preserved when the function participates in an external interface or is used through a C\-ABI function pointer\. When all uses are project\-local,PerfRremovesextern "C"and\#\[no\_mangle\], removes the corresponding external declarations, and rewrites callers to invoke the function directly through its Rust module path\.

Local Pointer\-View Recovery\.After restoring internal Rust call relationships, function bodies may still access objects and buffers through raw\-pointer parameters\. Following the pointer\-semantics recovery strategy of prior C\-to\-Rust translation work\[[13](https://arxiv.org/html/2610.23044#bib.bib2)\],PerfRanalyzes each raw\-pointer parameter to determine whether its accesses can be represented by a Rust reference or slice\. For a pointer to an individual object, it constructs a local&Tor&mut Tview; for a contiguous buffer, it recovers the accessed extent and constructs&\[T\]or&mut \[T\]\. Shared views require no conflicting writes, while mutable views additionally require exclusive access\. When these conditions cannot be established, the raw\-pointer representation is retained; otherwise, covered dereferences and pointer\-offset accesses are rewritten through the recovered view\.

Unsafe\-Boundary Narrowing\.Recovering references and slices reduces the code requiring an unsafe context but may leave caller\-side safety obligations\.PerfRtherefore reassesses each function\-levelunsafeannotation\. Theunsafe fnmarker is retained when callers must uphold safety preconditions that cannot be established within the function, such as raw\-pointer validity\. Otherwise,PerfRremoves the marker and confines unsafe operations to localunsafeblocks; blocks reported asunused\_unsafeby the compiler are then removed\.

### V\-CRule\-based Issue Localization

Project\-level performance optimization requires answering two questions: where optimization can materially affect end\-to\-end runtime, and what performance issues should be addressed there\.PerfRfirst profiles the performance workloads to localize project\-owned hot functions\.PerfRthen uses the*Observed Pattern*and corresponding*Optimization Direction*derived for each recurring issue in RQ3 \(§[IV\-C](https://arxiv.org/html/2610.23044#S4.SS3)\) to identify concrete optimization targets within these functions\.PerfRtherefore first localizes hot functions and then matches these patterns against their optimized IR, compiler remarks, and Rust source to identify concrete optimization targets\.

#### V\-C1Hotspot Identification

Project\-level optimization need not examine every function equally, since optimizing code with little runtime contribution yields limited end\-to\-end benefit\[[46](https://arxiv.org/html/2610.23044#bib.bib51),[47](https://arxiv.org/html/2610.23044#bib.bib52)\]\. Amdahl’s law further quantifies this limitation\[[48](https://arxiv.org/html/2610.23044#bib.bib53)\]: eliminating the execution cost of a region accounting for a runtime fractionppyields a speedup of at most1/\(1−p\)1/\(1\-p\)\.PerfRtherefore localizes project\-owned*hot functions*for subsequent optimization\.

To identify these functions,PerfRprofiles each performance workload usingperf, collecting cycle samples together with their call stacks, and attributes each sample to a project\-owned function\. Attribution by machine\-code symbol is unreliable for translated code: small project functions are often inlined into their callers, including the harness, and some project functions delegate their work to C library routines\. In both cases, the samples would be charged to code other than the function that should be rewritten\.PerfRtherefore expands inlined frames using debug information and attributes each sample to the deepest project\-owned frame on its call stack\. For samples in project\-owned code, attribution to the deepest project\-owned frame prevents callers from appearing hot because of expensive project callees\. Samples in non\-project code, such as C library routines, are instead attributed to the invoking project function, which is the actionable rewrite target\. Lets⁡\(f,w\)s\(f,w\)denote the fraction of cycle samples attributed to project\-owned functionffunder workloadww, referred to as its*attributed cycle share*\. Because hotspots may vary across workloads,PerfRdefines project\-level hotness ash⁡\(f\)=maxw∈𝒲perf⁡s⁡\(f,w\)h\(f\)=\\max\_\{w\\in\\mathcal\{W\}\_\{\\mathrm\{perf\}\}\}s\(f,w\), where𝒲perf\\mathcal\{W\}\_\{\\mathrm\{perf\}\}is the set of performance workloads\. Taking the maximum preserves workload\-specific hotspots that would be diluted by averaging across workloads\.PerfRranks functions byh⁡\(f\)h\(f\), discards those below the hotness threshold, and retains up to a fixed budget of the highest\-ranked functions, yieldingℋ=\{f1,f2,…,fn\}\\mathcal\{H\}=\\\{f\_\{1\},f\_\{2\},\\ldots,f\_\{n\}\\\}\.

#### V\-C2Issue Pattern Matching

Hotspot localization identifies which functions should be prioritized for optimization, but not the concrete performance issues within them\. We encode each performance issue identified in RQ3 \(§[IV\-C](https://arxiv.org/html/2610.23044#S4.SS3)\) as an*optimization rule*pairing its*Observed Pattern*with the corresponding*Optimization Direction*\. The former defines the matching criteria for identifying issue occurrences, while the latter guides subsequent rewriting\.PerfRrealizes the matching criteria through three analyzers over optimized IR, compiler remarks, and Rust source\. Although some patterns are derived using paired C–Rust evidence, matching relies only on Rust\-side artifacts\.

*Optimized IR Analyzer\.*PerfRcompiles the project to optimized LLVM IR with debug information and searches for rule\-specific IR signatures\. Survivingpanic\_bounds\_checkcalls are candidate matches for*Residual Bounds Checks*, whilellvm\.fptosi\.satandllvm\.fptoui\.satintrinsics are candidate matches for*Redundant Conversion Saturation*\.

*Optimization Remarks Analyzer\.*PerfRcompiles the project with optimization remarks enabled and matches remarks by their reporting pass and reason against the corresponding*Observed Pattern*\. Only remarks whose reported barriers conform to the corresponding*Observed Pattern*are retained\. For example, vectorization remarks reporting insufficient profitability are excluded, while inlining matches additionally require the call to remain in optimized IR\. GVN and LICM remarks attributing failed load elimination or hoisting to potentially clobbering stores are candidate matches for*Obscured Memory Access Properties*\.

*Rust Source Analyzer\.*PerfRparses the project into syntax trees and builds a project\-wide symbol index resolving types, globals, functions, and caller–callee relationships\. These representations enable structural matching of the source\-level*Observed Patterns*\. For example, a buffer that is repeatedly allocated and released or grown by fixed increments throughreallocis a candidate match for*Inefficient Buffer Management*\.

Applying these analyzers yields candidate occurrences of the identified performance issues, each associated with a matched rule and a source location\. Because the three analyzers report locations in different forms,PerfRnormalizes them before further processing: IR matches are mapped through debug metadata and inline\-call chains, optimization remarks provide compiler\-reported locations, and source matches directly identify syntax\-tree ranges\.PerfRthen converts these locations to project\-relative source ranges, associates each match with its enclosing source function, and retains only matches within the hot\-function setℋ\\mathcal\{H\}\. To remove duplicate matches and form coherent rewrite regions,PerfRconsolidates the retained matches in two stages\. First, matches that associate the same rule with the same source construct, including those from different analyzers, are merged into a single*pattern instance*\. Second, co\-located instances are combined into a*pattern group*when their source regions overlap, nest, or occur in nearby statements of the same block, subject to a bound on the enclosing region size; otherwise, an instance forms a singleton group\. Each group is anchored at the smallest enclosing syntactic region covering its instances, such as an expression, a statement sequence, or a loop\.

For each hot functionf∈ℋf\\in\\mathcal\{H\},PerfRrepresents the resulting groups asMf=\{⟨ℓi,Ri⟩\}i=1mf,M\_\{f\}=\\\{\\langle\\ell\_\{i\},R\_\{i\}\\rangle\\\}\_\{i=1\}^\{m\_\{f\}\},wheremfm\_\{f\}is the number of candidate optimization regions inff,ℓi\\ell\_\{i\}is the source region of theii\-th group, andRiR\_\{i\}is its set of matched optimization rules\. Each pair therefore specifies where to rewrite and which optimization directions to consider jointly\. For example, a residual bounds\-check match at an indexed expression and a vectorization\-failure match at its enclosing loop may be grouped at the loop level\. The resulting group contains both*Residual Bounds Checks*and*Missed Loop Vectorization*, allowing their optimization directions to be coordinated in a single rewrite\. These groups form the units for subsequent optimization\.

### V\-DLLM\-Based Rewrite Generation

A pattern group localizes a source region and associates it with one or more matched optimization rules\. A match, however, only indicates that the corresponding*Optimization Direction*may be relevant; applying that direction requires rewrite\-specific semantic preconditions that the*Observed Pattern*alone does not establish\. To make these requirements explicit,PerfRaugments each rule with*rewrite preconditions*\. These preconditions, together with the*Observed Pattern*and*Optimization Direction*, form an*optimization card*\. The LLM agent then evaluates these preconditions at the matched region before synthesizing a candidate rewrite\.

For each concrete rewrite form associated with an*Optimization Direction*, we identify the semantic obligations required to preserve the behavior of the original code\. These obligations follow from established legality conditions for the corresponding program transformation where applicable\[[49](https://arxiv.org/html/2610.23044#bib.bib65),[50](https://arxiv.org/html/2610.23044#bib.bib64)\]; otherwise, they are derived from the behavioral\-equivalence requirements of the rewrite\. When a rewrite introduces a Rust construct or API, we additionally incorporate its documented validity requirements\[[51](https://arxiv.org/html/2610.23044#bib.bib66)\]\. For example, Figure[2](https://arxiv.org/html/2610.23044#S5.F2)illustrates mutable\-slice recovery for*Obscured Memory Access Properties*: the corresponding card requires establishing the buffer extent, ensuring that accesses remain within that extent, and excluding conflicting accesses while the mutable slice is live\. We express these obligations as concrete checks over the target code, forming the card’s*rewrite\-precondition checklist*\.

To enable the LLM to assess the rewrite\-precondition checklist,PerfRprovides the program context needed to establish the required conditions\. For each pattern group⟨ℓi,ℛi⟩∈Mf\\langle\\ell\_\{i\},\\mathcal\{R\}\_\{i\}\\rangle\\in M\_\{f\},PerfRinstantiates the associated optimization cards as*matched optimization cards*by grounding each*Observed Pattern*in the corresponding source construct\. The enclosing function provides the local control\- and data\-flow context\. When a precondition depends on information beyond the function,PerfRretrieves relevant type, global, and function definitions, together with project\-local call sites, through the project\-wide symbol index as*dependency context*\. The source regionℓi\\ell\_\{i\}, matched cards, and collected context together form a region\-specific optimization prompt\. Figure[2](https://arxiv.org/html/2610.23044#S5.F2)illustrates this construction for thezrshloop, where the definitions ofzahlandzahl\_char\_tprovide dependency context for\(\*a\)\.chars\. Based on the region\-specific prompt, the agent first evaluates the rewrite preconditions of each matched card against the supplied program context\. Cards with unmet or unresolved preconditions are excluded; if no card remains,PerfRskips the region\. Otherwise, the agent jointly considers the*Optimization Directions*of the applicable cards and synthesizes a single*candidate rewrite*forℓi\\ell\_\{i\}\. When multiple directions affect overlapping code, they are coordinated within the same rewrite rather than applied independently\.

![Refer to caption](https://arxiv.org/html/2610.23044v1/pics/card.png)Fig\. 2:Region\-specific optimization prompt for thezrshloopPerfRapplies this procedure sequentially to all pattern groups, processing hot functions in descending order ofh⁡\(f\)h\(f\)\. Each group is optimized against the current accepted project version, so previously accepted rewrites are reflected in subsequent optimization\. After validation \(§[V\-E](https://arxiv.org/html/2610.23044#S5.SS5)\), an accepted rewrite becomes the new project version; otherwise, the current version is retained\. Because accepted rewrites may shift source locations or alter dependencies,PerfRre\-resolves the remaining groups against the updated project before continuing\.

### V\-EExecution\-based Rewrite Validation

Applying a candidate rewrite may cause either \(i\) behavioral deviation or \(ii\) runtime regression despite preserving behavior\.PerfRtherefore validates every candidate for both functionality and performance before acceptance\. The refined Rust project serves as the prepared baseline and initializes the current accepted version\. A candidate is applied to this version and becomes the new accepted version only if it passes both validations; otherwise, the previous version is restored\.

Functional Validation\.Before rewriting begins,PerfRreplays the functional workloads from §[V\-A](https://arxiv.org/html/2610.23044#S5.SS1)on the prepared baseline to verify their recorded reference digests\. For each candidate,PerfRrebuilds the project and re\-executes the same operation–input pairs with the same harnesses\. A candidate passes functional validation only if the build succeeds, all executions complete normally, and every output digest matches its reference\. Otherwise,PerfRinvokes a feedback\-driven repair loop following prior LLM\-based program repair\[[52](https://arxiv.org/html/2610.23044#bib.bib31),[13](https://arxiv.org/html/2610.23044#bib.bib2)\]\. The available diagnostics and source locations, together with the attempted rewrite and relevant program context, are returned to the agent for revision\. The revised candidate is rebuilt and revalidated until it passes or the repair budget is exhausted, after which the candidate is discarded\.

Performance Validation\.An*Optimization Direction*does not guarantee an end\-to\-end speedup, as semantics\-preserving rewrites may alter compiler optimizations and machine\-code layout\[[53](https://arxiv.org/html/2610.23044#bib.bib58),[54](https://arxiv.org/html/2610.23044#bib.bib59)\]\.PerfRtherefore evaluates each functionally valid candidate using two complementary performance gates\. Measurements use paired runs of the candidate and the corresponding reference version on each performance workload, with execution order alternated across pairs\. Confidence intervals are computed for per\-operation and aggregate runtime changes, and inconclusive cases receive additional measurements within a predefined budget\. The*incremental gate*compares the candidate against the current accepted version on workloads associated with the rewritten hot function, ensuring that the new rewrite does not introduce a statistically supported regression beyond the predefined tolerance\. Its aggregate decision weights operations by the hot function’s execution contribution\. The*cumulative gate*compares the candidate against the prepared baseline across all measurable performance workloads, ensuring that successive accepted rewrites continue to provide a project\-wide net gain\. It uses an equal\-weight aggregate and additionally guards against severe operation\-level regressions that could be hidden by the aggregate result\. Candidates with unresolved decisions or measurement failures at budget exhaustion are rejected\.

## VIEvaluation

TABLE V:Per\-operation runtime overhead over C on the Evaluation Dataset\. Positive values indicate slowdown and negative values speedup; n/e denotes non\-equivalent output\.ProjectOperationRawRustCodexRefinedPerfRRPerfRProjectOperationRawRustCodexRefinedPerfRRPerfRlibopenaptxaptX encoding\+3\.7%\+3\.7\\%n/e\+3\.7%\+3\.7\\%−5\.4%\-5\.4\\%−9\.0%\\mathbf\{\-9\.0\\%\}zopfliDEFLATE compression−25\.9%\-25\.9\\%−25\.9%\-25\.9\\%−25\.2%\-25\.2\\%−24\.9%\-24\.9\\%−31\.4%\\mathbf\{\-31\.4\\%\}aptX decoding\+15\.5%\+15\.5\\%n/e\+15\.8%\+15\.8\\%\+5\.1%\+5\.1\\%−1\.9%\\mathbf\{\-1\.9\\%\}lodepngPNG decoding\+10\.6%\+10\.6\\%\+5\.4%\+5\.4\\%\+11\.3%\+11\.3\\%\+4\.9%\\mathbf\{\+4\.9\\%\}\+5\.0%\+5\.0\\%Stream recovery\+9\.6%\+9\.6\\%n/e\+9\.7%\+9\.7\\%\+0\.1%\+0\.1\\%−5\.6%\\mathbf\{\-5\.6\\%\}PNG encoding\+0\.6%\+0\.6\\%−10\.8%\-10\.8\\%\+0\.8%\+0\.8\\%\+0\.2%\+0\.2\\%−15\.0%\\mathbf\{\-15\.0\\%\}http\-parserRequest parsing\+141\.8%\+141\.8\\%\+124\.1%\+124\.1\\%\+168\.2%\+168\.2\\%\+167\.5%\+167\.5\\%\+10\.1%\\mathbf\{\+10\.1\\%\}Color conversion−0\.1%\-0\.1\\%\+9\.7%\+9\.7\\%\+31\.8%\+31\.8\\%\+29\.2%\+29\.2\\%−45\.5%\\mathbf\{\-45\.5\\%\}Response parsing\+294\.8%\+294\.8\\%\+235\.3%\+235\.3\\%\+350\.0%\+350\.0\\%\+295\.0%\+295\.0\\%\+12\.3%\\mathbf\{\+12\.3\\%\}zlib processing\+1\.4%\+1\.4\\%−7\.9%\-7\.9\\%\+1\.1%\+1\.1\\%\+0\.3%\+0\.3\\%−25\.0%\\mathbf\{\-25\.0\\%\}Incremental parsing\+188\.9%\+188\.9\\%\+188\.1%\+188\.1\\%\+211\.5%\+211\.5\\%\+211\.0%\+211\.0\\%\+11\.7%\\mathbf\{\+11\.7\\%\}Chunk processing\+3\.4%\+3\.4\\%−0\.6%\\mathbf\{\-0\.6\\%\}−0\.3%\-0\.3\\%−0\.4%\-0\.4\\%−0\.3%\-0\.3\\%URL parsing−0\.3%\-0\.3\\%\+1\.2%\+1\.2\\%\+3\.2%\+3\.2\\%\+3\.3%\+3\.3\\%−28\.5%\\mathbf\{\-28\.5\\%\}libqrencodeQR encoding\+14\.8%\+14\.8\\%\+16\.5%\+16\.5\\%\+18\.0%\+18\.0\\%\+13\.0%\+13\.0\\%\+11\.2%\\mathbf\{\+11\.2\\%\}fzyFuzzy scoring\+32\.2%\+32\.2\\%\+14\.8%\+14\.8\\%\+32\.4%\+32\.4\\%\+31\.4%\+31\.4\\%\+13\.5%\\mathbf\{\+13\.5\\%\}Micro\-QR encoding\+1\.1%\+1\.1\\%n/e\+1\.6%\+1\.6\\%\+1\.6%\+1\.6\\%\+0\.6%\\mathbf\{\+0\.6\\%\}Choice\-list search\+51\.0%\+51\.0\\%\+44\.9%\+44\.9\\%\+52\.0%\+52\.0\\%\+50\.7%\+50\.7\\%\+36\.1%\\mathbf\{\+36\.1\\%\}Structured append\+16\.2%\+16\.2\\%\+19\.0%\+19\.0\\%\+19\.4%\+19\.4\\%\+14\.5%\+14\.5\\%\+13\.0%\\mathbf\{\+13\.0\\%\}Candidate\-list parsing\+50\.9%\+50\.9\\%\+44\.0%\+44\.0\\%\+51\.6%\+51\.6\\%\+50\.0%\+50\.0\\%\+38\.3%\\mathbf\{\+38\.3\\%\}optipngPNG optimization\+1\.7%\+1\.7\\%\+1\.7%\+1\.7\\%\+1\.7%\+1\.7\\%\+1\.7%\+1\.7\\%\+1\.5%\\mathbf\{\+1\.5\\%\}lilScript execution−1\.5%\-1\.5\\%−5\.6%\-5\.6\\%−1\.7%\-1\.7\\%−2\.0%\-2\.0\\%−9\.4%\\mathbf\{\-9\.4\\%\}Format conversion\+1\.4%\+1\.4\\%\+0\.6%\\mathbf\{\+0\.6\\%\}\+1\.0%\+1\.0\\%\+0\.9%\+0\.9\\%\+0\.6%\\mathbf\{\+0\.6\\%\}Embedding API\+11\.1%\+11\.1\\%−6\.3%\\mathbf\{\-6\.3\\%\}\+12\.6%\+12\.6\\%\+11\.7%\+11\.7\\%−1\.7%\-1\.7\\%brotliCompression\+3\.7%\+3\.7\\%\+1\.6%\\mathbf\{\+1\.6\\%\}\+3\.7%\+3\.7\\%\+3\.6%\+3\.6\\%\+4\.0%\+4\.0\\%minizCompression\+2\.3%\+2\.3\\%\+2\.3%\+2\.3\\%\+2\.4%\+2\.4\\%\+2\.7%\+2\.7\\%\+1\.5%\\mathbf\{\+1\.5\\%\}Decompression\+13\.4%\+13\.4\\%\+13\.4%\+13\.4\\%\+14\.7%\+14\.7\\%\+14\.9%\+14\.9\\%\+9\.6%\\mathbf\{\+9\.6\\%\}Decompression\+25\.6%\+25\.6\\%\+7\.3%\\mathbf\{\+7\.3\\%\}\+25\.4%\+25\.4\\%\+25\.2%\+25\.2\\%\+12\.5%\+12\.5\\%Streaming\+4\.1%\+4\.1\\%\+4\.0%\+4\.0\\%\+2\.8%\+2\.8\\%\+2\.7%\+2\.7\\%\+2\.2%\\mathbf\{\+2\.2\\%\}Streaming\+12\.7%\+12\.7\\%\+6\.4%\\mathbf\{\+6\.4\\%\}\+12\.6%\+12\.6\\%\+12\.7%\+12\.7\\%\+6\.8%\+6\.8\\%Dictionary modes\+6\.5%\+6\.5\\%\+6\.6%\+6\.6\\%\+6\.6%\+6\.6\\%\+6\.2%\+6\.2\\%\+5\.7%\\mathbf\{\+5\.7\\%\}Checksums\+16\.7%\+16\.7\\%\+16\.7%\+16\.7\\%\+16\.7%\+16\.7\\%\+16\.7%\+16\.7\\%−66\.0%\\mathbf\{\-66\.0\\%\}libxml2Parsing\+2\.1%\+2\.1\\%\+2\.1%\+2\.1\\%\+1\.9%\+1\.9\\%\+1\.2%\\mathbf\{\+1\.2\\%\}\+1\.4%\+1\.4\\%ZIP processing\+4\.9%\+4\.9\\%\+2\.3%\+2\.3\\%\+4\.9%\+4\.9\\%\+5\.1%\+5\.1\\%−28\.1%\\mathbf\{\-28\.1\\%\}Validation\+1\.0%\+1\.0\\%\+0\.8%\+0\.8\\%−0\.1%\-0\.1\\%−0\.1%\-0\.1\\%−0\.6%\\mathbf\{\-0\.6\\%\}lz4Compression\+3\.2%\+3\.2\\%\+3\.3%\+3\.3\\%\+1\.5%\\mathbf\{\+1\.5\\%\}\+1\.5%\\mathbf\{\+1\.5\\%\}\+1\.6%\+1\.6\\%XPath Evaluation\+0\.5%\+0\.5\\%\+0\.6%\+0\.6\\%−1\.1%\-1\.1\\%−1\.5%\\mathbf\{\-1\.5\\%\}−0\.9%\-0\.9\\%Decompression\+9\.8%\+9\.8\\%\+17\.5%\+17\.5\\%\+14\.2%\+14\.2\\%\+14\.1%\+14\.1\\%\+6\.9%\\mathbf\{\+6\.9\\%\}Serialization−1\.1%\-1\.1\\%−1\.4%\-1\.4\\%−2\.1%\\mathbf\{\-2\.1\\%\}−1\.6%\-1\.6\\%−1\.7%\-1\.7\\%Streaming\+5\.5%\+5\.5\\%\+8\.8%\+8\.8\\%\+2\.4%\+2\.4\\%\+2\.4%\+2\.4\\%−1\.0%\\mathbf\{\-1\.0\\%\}Dictionary/URI/string utilities\+13\.1%\+13\.1\\%\+11\.4%\+11\.4\\%\+6\.3%\\mathbf\{\+6\.3\\%\}\+7\.1%\+7\.1\\%\+7\.6%\+7\.6\\%Dictionary modes\+3\.1%\+3\.1\\%\+5\.6%\+5\.6\\%\+1\.4%\+1\.4\\%\+1\.4%\+1\.4\\%−1\.7%\\mathbf\{\-1\.7\\%\}

We evaluatePerfRon the Evaluation Dataset to answer two research questions:RQ4 \(Optimization Effectiveness\): How effectively doesPerfRreduce the performance gap between translated Rust and C, and how does it compare with a general\-purpose coding agent?RQ5 \(Ablation Study\): What contributes to the performance improvement ofPerfR, and what is the contribution of rule guidance?

### VI\-AEvaluation Setup

Implementation\.PerfRcombines AST\-based Rust source analysis with a project\-wide symbol index, optimized LLVM IR and optimization\-remark analysis, andperf\-based cycle profiling\. All LLM\-based components use GPT\-5\.4\[[55](https://arxiv.org/html/2610.23044#bib.bib45)\]\. Workload synthesis targets 70% public\-function coverage, with at most three coverage\-refinement rounds and five harness\-repair attempts\. Hotspot localization retains project\-owned functions with project\-level hotnessh⁡\(f\)h\(f\)of at least 3%\. Internal performance validation uses two\-sided 95% confidence intervals with adaptive sampling at 10, 20, and 40 measurement pairs\. The per\-operation and aggregate regression tolerances are 1\.0% and 0\.3%, respectively, and accepted rewrites must provide at least 0\.1% project\-wide net gain\.

Baselines\.We use the C implementation as the runtime reference andRawRustas the unoptimized Rust baseline\. As an external baseline, we useCodex\[[56](https://arxiv.org/html/2610.23044#bib.bib63)\], a general\-purpose coding agent, and instruct it to optimize eachRawRustproject for runtime performance\. For RQ5, we additionally considerRefined, the output of Pre\-optimization Normalization \(§[V\-B](https://arxiv.org/html/2610.23044#S5.SS2)\), andPerfRR, which omits optimization cards from rewrite\-generation prompts while retaining the rest of the pipeline\.

Evaluation Settings\.We use the Evaluation Dataset workloads, build configuration, execution environment, measurement protocol, and runtime\-overhead metric defined in §[III\-A](https://arxiv.org/html/2610.23044#S3.SS1)and §[III\-B](https://arxiv.org/html/2610.23044#S3.SS2)\. To control code\-placement effects in per\-operation comparisons, we additionally compile all variants, including C, with 64\-byte function alignment\. We runCodexusing CLI v0\.153\.4 with the same GPT\-5\.4 model asPerfRand reasoning effort set tohigh\. For each project,Codexreceives the completeRawRustproject and is instructed to optimize runtime performance while preserving program behavior, with a 30\-minute budget\. We evaluate all variants on the same workloads and report timings only for operation–input pairs whose outputs are identical to those of C\.

### VI\-BRQ4: Optimization Effectiveness

Table[V](https://arxiv.org/html/2610.23044#S6.T5)reports the per\-operation runtime overhead relative to C forRawRust,Codex, andPerfRacross 41 operations from 12 projects\. Overall,PerfRreduces measured runtime relative toRawRuston 40 of the 41 operations\. The improvement is particularly large forhttp\-parser: across its three message\-parsing operations, overhead decreases from as high as294\.8%294\.8\\%forRawRustto at most12\.3%12\.3\\%forPerfR\. After optimization, 18 operations run faster than C, including 10 by more than 3%\. The largest gain relative to C occurs onminizchecksum computation, where overhead changes from\+16\.7%\+16\.7\\%forRawRustto−66\.0%\-66\.0\\%forPerfR\.

Compared withCodex,PerfRpreserves output equivalence on more operations and achieves lower runtime on most comparable cases\.Codexproduces non\-equivalent outputs on four operations, whereasPerfRremains output\-equivalent to C on all 41\. Among the 37 operations for which both produce equivalent outputs,PerfRachieves lower measured runtime on 31, compared with five forCodex, with one tie; its largest speedup overCodexreaches3\.4×3\.4\\timesonminizchecksum computation\.

Finding 4:PerfReffectively recovers translation\-induced performance loss, achieving competitive or better performance than C while preserving behavior and outperforming a general\-purpose coding agent overall\.

### VI\-CRQ5: Ablation Study

Table[V](https://arxiv.org/html/2610.23044#S6.T5)comparesRefined,PerfRR, andPerfRto assess the contribution of rule guidance\. Translation Refinement and unguided optimization can both improve runtime on individual operations, but their gains are limited compared withPerfR\. Overall,PerfRachieves lower measured runtime thanPerfRRon 34 of the 41 operations\. For example, onlz4streaming and dictionary modes, overhead decreases from\+5\.5%\+5\.5\\%and\+3\.1%\+3\.1\\%forRawRustto\+2\.4%\+2\.4\\%and\+1\.4%\+1\.4\\%after refinement\. These values remain unchanged underPerfRR, whereasPerfRfurther reduces them to−1\.0%\-1\.0\\%and−1\.7%\-1\.7\\%, respectively\. A larger gap appears forlodepngzlib processing, where overhead is\+1\.1%\+1\.1\\%after refinement and\+0\.3%\+0\.3\\%underPerfRR, but drops to−25\.0%\-25\.0\\%underPerfR\. These results indicate that the derived rules provide effective guidance for recovering performance beyond what refinement and unguided optimization can achieve\.

To understand how rule guidance contributes to these gains, we further examine the rewrites retained after validation\.PerfRyields 62 accepted rewrites, compared with 28 forPerfRR\. The two variants also differ in the types of transformations they produce\. Among the 28 rewrites accepted underPerfRR, 16 are local cleanups; none recovers additional slice views or removes residual bounds checks, leaving the raw\-pointer accesses remaining after refinement unchanged\. In contrast, 46 of the 62 rewrites accepted byPerfRinvolve*Memory Property Recovery*, making access relationships and invariants explicit to LLVM\. These results indicate that rule guidance changes not only the number but also the nature of accepted rewrites, directing optimization toward the performance mechanisms identified in our empirical study\.

Finding 5:The optimization rules distilled from our study effectively guide the recovery of translation\-induced performance loss, substantially outperforming unguided optimization\.

## VIIDiscussion

### VII\-ASources of Performance Improvement

Among the 41 Evaluation\-Dataset operations,RawRustincurs more than 3% overhead over C on 27\. We apply the RQ2 decomposition to these regressions\. Among them, 16 execute more instructions at lower CPI, nine increase both instruction count and CPI, and two increase CPI alone\. Thus, instruction inflation appears in 25 of 27 regressions and remains the predominant overhead source\.

Across the 27 regressions,PerfRreduces the geometric mean ofRinstR\_\{\\mathrm\{inst\}\}from 1\.287 to 1\.012, whileRCPIR\_\{\\mathrm\{CPI\}\}remains near unity \(0\.987 to 1\.003\), indicating that performance recovery primarily comes from eliminating translation\-induced extra instructions\. Residual slowdowns, however, can still be CPI\-dominated\. The two largest,fzychoice\-list search and candidate\-list parsing, execute fewer instructions than C after optimization but remain slower because of higher CPI, with TMA attributing most of the gap to Core Bound and Memory Bound\.

Despite this overall trend, individual rule\-guided rewrites can also reduce per\-instruction cost\. Inminizchecksum computation, a rewrite for*Scalar Element\-Wise Processing*replaces byte\-wise processing with an equivalent block\-wise formulation\. The optimized code executes nearly the same number of instructions as C \(Rinst=0\.986R\_\{\\mathrm\{inst\}\}=0\.986\) but at roughly one third of its CPI \(RCPI=0\.344R\_\{\\mathrm\{CPI\}\}=0\.344\); TMA likewise shows Memory Bound decreasing from 47% in C to 11% underPerfR\. This case shows that rule\-guided rewriting can improve efficiency not only by reducing extra work, but also by lowering per\-instruction cost\.

### VII\-BCross\-Project Applicability of Optimization Rules

The optimization rules operationalized from the RQ3 findings recur broadly across the 12 disjoint Evaluation projects\. At least one rule\-specific pattern is detected in 94% of the hot functions; every project exhibits patterns associated with at least three rules \(median: four\), and all nine rules contribute to accepted rewrites\. Together, these results indicate that the optimization knowledge identified in the Study Dataset remains applicable beyond the projects used for its derivation\.

The prevalence of matched patterns varies substantially across rules\.*Obscured Memory Access Properties*is the most widespread, matching 89% of the hot functions across all 12 projects and contributing to accepted rewrites in 11\.*Byte\-Oriented Memory Operations*is also common, matching 35% of the hot functions across 11 projects\. Other source\-level patterns occur less frequently, reflecting their narrower structural conditions\. Compiler\-level issues are likewise detected across projects:*Residual Bounds Checks*,*Missed Hot\-Callee Inlining*, and*Missed Loop Vectorization*match 18%, 16%, and 24% of the hot functions, respectively\. Together, these results show that cross\-project applicability spans both source\-level patterns and compiler\-level optimization losses\.

### VII\-CImpact on Safety

Beyond runtime performance, we examine the safety\-related effects ofPerfRacross the 12 projects, considering both the caller\-visibleunsafeinterface and raw\-pointer use within rewritten functions\. InRawRust,99\.8%99\.8\\%of functions are declaredunsafe fn;Codexleaves this proportion unchanged, whereasPerfRreduces it to60\.5%60\.5\\%, increasing the proportion of functions callable from safe Rust from0\.2%0\.2\\%to39\.5%39\.5\\%\. This narrower interface is established during Translation Refinement and preserved by subsequent optimization\. Relative toRefined, the optimized functions further reduce pointer\-arithmetic operations by18%18\\%and raw\-pointer dereferences by10%10\\%through transformations such as slice\-based traversal and iterator\-based access\. Overall,PerfRimproves performance while narrowing the caller\-visible unsafe interface and further reducing reliance on raw\-pointer memory operations\.

## VIIIThreats to Validity

One threat concerns the sensitivity of runtime measurements to system noise\. We mitigate this threat by using five warm\-up rounds and 30 paired measurements for each workload, alternating the C–Rust execution order, and compiling all compared variants with consistent function alignment\. Another threat concerns the representativeness of performance evaluation within each project\. Rather than using a single whole\-project runtime or isolated API calls, we evaluate semantically complete end\-to\-end operations that exercise distinct implementation paths and use multiple operations when a project contains different performance\-relevant functionalities\. A third threat concerns potential bias in the optimization rules toward the projects from which they are derived\. We mitigate this threat by deriving the rules exclusively from the eight Study\-Dataset projects and reserving twelve disjoint projects for evaluation\.

## IXRelated Work

Automated code translation spans both function\- and project\-level migration across multiple language pairs\[[57](https://arxiv.org/html/2610.23044#bib.bib17),[58](https://arxiv.org/html/2610.23044#bib.bib33),[59](https://arxiv.org/html/2610.23044#bib.bib29),[60](https://arxiv.org/html/2610.23044#bib.bib38),[61](https://arxiv.org/html/2610.23044#bib.bib37),[62](https://arxiv.org/html/2610.23044#bib.bib40),[63](https://arxiv.org/html/2610.23044#bib.bib39),[64](https://arxiv.org/html/2610.23044#bib.bib16)\]\. We focus on project\-level C\-to\-Rust translation, where existing approaches broadly follow two routes\. LLM\-based translators aim to generate safer and more idiomatic Rust, increasingly leveraging program analysis and project\-wide context to improve translation quality\[[65](https://arxiv.org/html/2610.23044#bib.bib13),[21](https://arxiv.org/html/2610.23044#bib.bib12),[12](https://arxiv.org/html/2610.23044#bib.bib15),[13](https://arxiv.org/html/2610.23044#bib.bib2)\]\. Preserving source behavior, however, remains challenging at project scale\. Rule\-based translators such as Corrode\[[66](https://arxiv.org/html/2610.23044#bib.bib42)\]andc2rust\[[8](https://arxiv.org/html/2610.23044#bib.bib41)\]instead apply deterministic transformations to C constructs, yielding reproducible translations intended to preserve source behavior\. Such translations often retain C\-oriented representations, including raw pointers and extensiveunsafecode\[[10](https://arxiv.org/html/2610.23044#bib.bib24)\]\. To improve C\-to\-Rust translation, prior work has explored program\-analysis\-based refinement\[[10](https://arxiv.org/html/2610.23044#bib.bib24),[19](https://arxiv.org/html/2610.23044#bib.bib23),[9](https://arxiv.org/html/2610.23044#bib.bib11)\], LLM\-guided rewriting\[[65](https://arxiv.org/html/2610.23044#bib.bib13),[21](https://arxiv.org/html/2610.23044#bib.bib12)\], and project\-wide reasoning over dependencies and pointer semantics\[[12](https://arxiv.org/html/2610.23044#bib.bib15),[13](https://arxiv.org/html/2610.23044#bib.bib2)\]\. These efforts primarily target behavioral preservation, safety, and idiomaticity\. In contrast,PerfRstarts from mechanically translated Rust and focuses on recovering runtime performance lost during translation\.

Recent work has begun to investigate performance regressions introduced by C\-to\-Rust translation\. Xia et al\. compare randomly generated C programs with theirc2rusttranslations and identify Relooper\-induced code duplication as one source of runtime overhead\[[24](https://arxiv.org/html/2610.23044#bib.bib54)\], while RUSTY targets this control\-flow expansion through a specialized translation scheme\[[27](https://arxiv.org/html/2610.23044#bib.bib55)\]\. However, they either rely on synthetic programs or address a specific translation\-induced mechanism, leaving performance divergence and recurring code\-level causes in real\-world projects less well characterized\. Beyond translation\-specific performance studies, SemOpt derives reusable optimization strategies from historical commits\[[28](https://arxiv.org/html/2610.23044#bib.bib56)\], and MoST extends such knowledge across multiple sources, languages, and scenarios\[[29](https://arxiv.org/html/2610.23044#bib.bib57)\]\. While these approaches demonstrate the value of rule\-guided optimization, their guidance is general\-purpose rather than derived from performance differences introduced by code translation\. Our work connects these two directions by analyzing paired C–Rust performance in real\-world projects, distilling recurring code\-level performance patterns and optimization directions into reusable rules, and applying them to guide post\-translation performance recovery\.

## XConclusion

Across 20 real\-world projects, we studied performance degradation in automated C\-to\-Rust translation and identified nine recurring performance issues and optimization directions through paired C–Rust analysis\. We then developedPerfR, a rule\-guided framework for locating and optimizing these issues\. On twelve held\-out projects,PerfRpreserves C outputs on all 41 operations and improves runtime overc2ruston 40, demonstrating the value of empirically derived knowledge for cross\-project performance recovery\.

## References

- \[1\]\(2022\)How ISO C became unusable for operating systems development\.CoRRabs/2201\.07845\.External Links:[Link](https://arxiv.org/abs/2201.07845),2201\.07845Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1)\.
- \[2\]R\. Patel and A\. Rajawat\(2013\)A survey of embedded software profiling methodologies\.CoRRabs/1312\.2949\.External Links:[Link](http://arxiv.org/abs/1312.2949),1312\.2949Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1)\.
- \[3\]J\. Fan, Y\. Li, S\. Wang, and T\. N\. Nguyen\(2020\)AC/c\+\+ code vulnerability dataset with code changes and cve summaries\.InProceedings of the 17th international conference on mining software repositories,pp\. 508–512\.Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1)\.
- \[4\]Z\. Hanley\(2023\)Rust won’t save us: an analysis of 2023’s known exploited vulnerabilities\.Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1)\.
- \[5\]N\. D\. Matsakis and F\. S\. Klock\(2014\)The rust language\.InProceedings of the 2014 ACM SIGAda annual conference on High integrity language technology,pp\. 103–104\.Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1)\.
- \[6\]X\. Zheng, Z\. Wan, Y\. Zhang, R\. Chang, and D\. Lo\(2024\)A closer look at the security risks in the rust ecosystem\.ACM Trans\. Softw\. Eng\. Methodol\.33\(2\),pp\. 34:1–34:30\.External Links:[Link](https://doi.org/10.1145/3624738),[Document](https://dx.doi.org/10.1145/3624738)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1)\.
- \[7\]Rust\-for\-LinuxExternal Links:[Link](https://github.com/Rust-for-Linux/linux)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1)\.
- \[8\]c2rust\(2025\)External Links:[Link](https://github.com/immunant/c2rust)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1),[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§I](https://arxiv.org/html/2610.23044#S1.p5.1),[§III](https://arxiv.org/html/2610.23044#S3.p1.1),[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[9\]H\. Zhang, C\. David, Y\. Yu, and M\. Wang\(2023\)Ownership guided C to rust translation\.InComputer Aided Verification \- 35th International Conference, CAV 2023, Paris, France, July 17\-22, 2023, Proceedings, Part III,Lecture Notes in Computer Science, Vol\.13966,pp\. 459–482\.External Links:[Link](https://doi.org/10.1007/978-3-031-37709-9/_22),[Document](https://dx.doi.org/10.1007/978-3-031-37709-9%5F22)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1),[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1),[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[10\]M\. Emre, R\. Schroeder, K\. Dewey, and B\. Hardekopf\(2021\)Translating C to safer rust\.Proc\. ACM Program\. Lang\.5\(OOPSLA\),pp\. 1–29\.External Links:[Link](https://doi.org/10.1145/3485498),[Document](https://dx.doi.org/10.1145/3485498)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1),[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§I](https://arxiv.org/html/2610.23044#S1.p5.1),[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1),[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[11\]H\. F\. Eniser, H\. Zhang, C\. David, M\. Wang, M\. Christakis, B\. Paulsen, J\. Dodds, and D\. Kroening\(2024\)Towards translating real\-world code with llms: A study of translating to rust\.CoRRabs/2405\.11514\.External Links:[Link](https://doi.org/10.48550/arXiv.2405.11514),[Document](https://dx.doi.org/10.48550/ARXIV.2405.11514),2405\.11514Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p1.1)\.
- \[12\]X\. Cai, J\. Liu, X\. Huang, Y\. Yu, H\. Wu, C\. Li, B\. Wang, I\. N\. B\. Yusuf, and L\. Jiang\(2025\)RustMap: towards project\-scale c\-to\-rust migration via program analysis and LLM\.CoRRabs/2503\.17741\.External Links:[Link](https://doi.org/10.48550/arXiv.2503.17741),[Document](https://dx.doi.org/10.48550/ARXIV.2503.17741),2503\.17741Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[13\]Z\. Yuan, W\. Mao, Z\. Chen, X\. Shang, C\. Wang, Y\. Lou, and X\. Peng\(2026\)Project\-level c\-to\-rust translation via pointer knowledge graphs\.Proc\. ACM Softw\. Eng\.3\(FSE\),pp\. 3675–3698\.External Links:[Link](https://doi.org/10.1145/3808169),[Document](https://dx.doi.org/10.1145/3808169)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1),[§V\-A](https://arxiv.org/html/2610.23044#S5.SS1.p3.1),[§V\-B2](https://arxiv.org/html/2610.23044#S5.SS2.SSS2.p2.1),[§V\-E](https://arxiv.org/html/2610.23044#S5.SS5.p2.1),[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[14\]M\. Shetty, N\. Jain, A\. Godbole, S\. A\. Seshia, and K\. Sen\(2024\)Syzygy: dual code\-test C to \(safe\) rust translation using llms and dynamic analysis\.CoRRabs/2412\.14234\.External Links:[Link](https://doi.org/10.48550/arXiv.2412.14234),[Document](https://dx.doi.org/10.48550/ARXIV.2412.14234),2412\.14234Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1)\.
- \[15\]J\. Hong and S\. Ryu\(2025\)Type\-migrating c\-to\-rust translation using a large language model\.Empir\. Softw\. Eng\.30\(1\),pp\. 3\.External Links:[Link](https://doi.org/10.1007/s10664-024-10573-2),[Document](https://dx.doi.org/10.1007/S10664-024-10573-2)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1)\.
- \[16\]M\. Shiraishi and T\. Shinagawa\(2024\)Context\-aware code segmentation for c\-to\-rust translation using large language models\.CoRRabs/2409\.10506\.External Links:[Link](https://doi.org/10.48550/arXiv.2409.10506),[Document](https://dx.doi.org/10.48550/ARXIV.2409.10506),2409\.10506Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1)\.
- \[17\]G\. Ou, M\. Liu, Y\. Chen, X\. Peng, and Z\. Zheng\(2024\)Repository\-level code translation benchmark targeting rust\.CoRRabs/2411\.13990\.External Links:[Link](https://doi.org/10.48550/arXiv.2411.13990),[Document](https://dx.doi.org/10.48550/ARXIV.2411.13990),2411\.13990Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1)\.
- \[18\]J\. Hong and S\. Ryu\(2024\)To tag, or not to tag: translating c’s unions to rust’s tagged unions\.InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ASE 2024, Sacramento, CA, USA, October 27 \- November 1, 2024,V\. Filkov, B\. Ray, and M\. Zhou \(Eds\.\),pp\. 40–52\.External Links:[Link](https://doi.org/10.1145/3691620.3694985),[Document](https://dx.doi.org/10.1145/3691620.3694985)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§I](https://arxiv.org/html/2610.23044#S1.p3.1)\.
- \[19\]M\. Emre, P\. Boyland, A\. Parekh, R\. Schroeder, K\. Dewey, and B\. Hardekopf\(2023\)Aliasing limits on translating C to safe rust\.Proc\. ACM Program\. Lang\.7\(OOPSLA1\),pp\. 551–579\.External Links:[Link](https://doi.org/10.1145/3586046),[Document](https://dx.doi.org/10.1145/3586046)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[20\]openEuler\(2022\)curl\-rust: rewrite memory leak related modules for cURL using Rust\(Website\)External Links:[Link](https://atomgit.com/openeuler/curl-rust)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§I](https://arxiv.org/html/2610.23044#S1.p5.1)\.
- \[21\]Y\. Gao, C\. Wang, P\. Huang, X\. Liu, M\. Zheng, and X\. Zhang\(2025\)PR2: peephole raw pointer rewriting with llms for translating C to safer rust\.CoRRabs/2505\.04852\.External Links:[Link](https://doi.org/10.48550/arXiv.2505.04852),[Document](https://dx.doi.org/10.48550/ARXIV.2505.04852),2505\.04852Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1),[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[22\]J\. Hong and S\. Ryu\(2025\)Forcrat: automatic I/O API translation from C to rust via origin and capability analysis\.CoRRabs/2506\.01427\.External Links:[Link](https://doi.org/10.48550/arXiv.2506.01427),[Document](https://dx.doi.org/10.48550/ARXIV.2506.01427),2506\.01427Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1),[§I](https://arxiv.org/html/2610.23044#S1.p3.1)\.
- \[23\]M\. Farrukh, S\. Shah, B\. Coskun, and M\. Polychronakis\(2025\)SafeTrans: llm\-assisted tran2spilation from C to rust\.CoRRabs/2505\.10708\.External Links:[Link](https://doi.org/10.48550/arXiv.2505.10708),[Document](https://dx.doi.org/10.48550/ARXIV.2505.10708),2505\.10708Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p2.1)\.
- \[24\]L\. Xia, B\. Hua, and Z\. Peng\(2023\)An empirical study of c to rust transpilers\.School of Software Engineering, University of Science and Technology of China, and Suzhou Institute for Advanced Research, University of Science and Technology of China\-04/27\.Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p3.1),[§IX](https://arxiv.org/html/2610.23044#S9.p2.1)\.
- \[25\]R\. Li, B\. Wang, T\. Li, P\. Saxena, and A\. Kundu\(2025\)Translating C to rust: lessons from a user study\.In32nd Annual Network and Distributed System Security Symposium, NDSS 2025, San Diego, California, USA, February 24\-28, 2025,External Links:[Link](https://www.ndss-symposium.org/ndss-paper/translating-c-to-rust-lessons-from-a-user-study/)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p3.1),[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1)\.
- \[26\]B\. Tadesse, V\. Nitin, M\. Salah, B\. Ray, M\. d’Amorim, and W\. Assunção\(2026\)Code quality analysis of translations from C to rust\.CoRRabs/2602\.00840\.External Links:[Link](https://doi.org/10.48550/arXiv.2602.00840),[Document](https://dx.doi.org/10.48550/ARXIV.2602.00840),2602\.00840Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p3.1)\.
- \[27\]X\. Han, B\. Hua, Y\. Wang, and Z\. Zhang\(2022\)RUSTY: effective C to rust conversion via unstructured control specialization\.In22nd IEEE International Conference on Software Quality, Reliability, and Security, QRS 2022 \- Companion, Guangzhou, China, December 5\-9, 2022,pp\. 760–761\.External Links:[Link](https://doi.org/10.1109/QRS-C57518.2022.00122),[Document](https://dx.doi.org/10.1109/QRS-C57518.2022.00122)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p3.1),[§IX](https://arxiv.org/html/2610.23044#S9.p2.1)\.
- \[28\]Y\. Zhao, Y\. Xiao, Q\. Xiao, Z\. Zhang, and Y\. Xiong\(2025\)SemOpt: llm\-driven code optimization via rule\-based analysis\.CoRRabs/2510\.16384\.External Links:[Link](https://doi.org/10.48550/arXiv.2510.16384),[Document](https://dx.doi.org/10.48550/ARXIV.2510.16384),2510\.16384Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p3.1),[§IX](https://arxiv.org/html/2610.23044#S9.p2.1)\.
- \[29\]Y\. Zhao, Q\. Xiao, Y\. Cui, Y\. Yu, and Y\. Xiong\(2026\)Multi\-source and cross\-scenario strategy\-guided code optimization\.CoRRabs/2607\.20353\.External Links:[Link](https://doi.org/10.48550/arXiv.2607.20353),[Document](https://dx.doi.org/10.48550/ARXIV.2607.20353),2607\.20353Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p3.1),[§IX](https://arxiv.org/html/2610.23044#S9.p2.1)\.
- \[30\]M\. Ling, Y\. Yu, H\. Wu, Y\. Wang, J\. R\. Cordy, and A\. E\. Hassan\(2022\)In rust we trust \- A transpiler from unsafe C to safer rust\.In44th IEEE/ACM International Conference on Software Engineering: Companion Proceedings, ICSE Companion 2022, Pittsburgh, PA, USA, May 22\-24, 2022,pp\. 354–355\.External Links:[Link](https://doi.org/10.1145/3510454.3528640),[Document](https://dx.doi.org/10.1145/3510454.3528640)Cited by:[§I](https://arxiv.org/html/2610.23044#S1.p5.1)\.
- \[31\]C\. Lattner and V\. S\. Adve\(2004\)LLVM: A compilation framework for lifelong program analysis & transformation\.In2nd IEEE / ACM International Symposium on Code Generation and Optimization \(CGO 2004\), 20\-24 March 2004, San Jose, CA, USA,pp\. 75–88\.External Links:[Link](https://doi.org/10.1109/CGO.2004.1281665),[Document](https://dx.doi.org/10.1109/CGO.2004.1281665)Cited by:[§II](https://arxiv.org/html/2610.23044#S2.p1.1)\.
- \[32\]The Rust Project DevelopersOverview of the compiler\.Note:Rust Compiler Development GuideExternal Links:[Link](https://rustc-dev-guide.rust-lang.org/overview.html)Cited by:[§II](https://arxiv.org/html/2610.23044#S2.p1.1)\.
- \[33\]D\. A\. Patterson and J\. L\. Hennessy\(1990\)Computer architecture: A quantitative approach\.Morgan Kaufmann\.External Links:ISBN 1\-55860\-188\-0Cited by:[§II](https://arxiv.org/html/2610.23044#S2.p2.1)\.
- \[34\]A\. Yasin\(2014\)A top\-down method for performance analysis and counters architecture\.In2014 IEEE International Symposium on Performance Analysis of Systems and Software, ISPASS 2014, Monterey, CA, USA, March 23\-25, 2014,pp\. 35–44\.External Links:[Link](https://doi.org/10.1109/ISPASS.2014.6844459),[Document](https://dx.doi.org/10.1109/ISPASS.2014.6844459)Cited by:[§II](https://arxiv.org/html/2610.23044#S2.p2.1)\.
- \[35\]J\. Hong and S\. Ryu\(2024\)Don’t write, but return: replacing output parameters with algebraic data types in c\-to\-rust translation\.Proc\. ACM Program\. Lang\.8\(PLDI\),pp\. 716–740\.External Links:[Link](https://doi.org/10.1145/3656406),[Document](https://dx.doi.org/10.1145/3656406)Cited by:[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1)\.
- \[36\]M\. Sirlanci, C\. Yagemann, and Z\. Lin\(2025\)C2RUST\-BENCH: A minimized, representative dataset for c\-to\-rust transpilation evaluation\.CoRRabs/2504\.15144\.External Links:[Link](https://doi.org/10.48550/arXiv.2504.15144),[Document](https://dx.doi.org/10.48550/ARXIV.2504.15144),2504\.15144Cited by:[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1)\.
- \[37\]xxHashExternal Links:[Link](https://github.com/Cyan4973/xxHash)Cited by:[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1)\.
- \[38\]lz4External Links:[Link](https://github.com/lz4/lz4)Cited by:[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1)\.
- \[39\]minizExternal Links:[Link](https://github.com/richgel999/miniz)Cited by:[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1)\.
- \[40\]parserExternal Links:[Link](https://github.com/nodejs/http-parser)Cited by:[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p1.1)\.
- \[41\]S\. Deorowicz\(2003\)Silesia compression corpus\.External Links:[Link](https://sun.aei.polsl.pl/~sdeor/index.php?page=silesia)Cited by:[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p3.1)\.
- \[42\]M\. Yip\(2016\)Native json benchmark\.External Links:[Link](https://github.com/miloyip/nativejson-benchmark)Cited by:[§III\-A](https://arxiv.org/html/2610.23044#S3.SS1.p3.1)\.
- \[43\]J\. W\. Tukey\(1977\)Exploratory data analysis\.Addison\-Wesley\.External Links:[Link](https://archive.org/details/exploratorydataa0000tuke_7616)Cited by:[§III\-B](https://arxiv.org/html/2610.23044#S3.SS2.p3.1)\.
- \[44\]N\. Nethercoteet al\.\(2020\)The Rust performance book\.External Links:[Link](https://nnethercote.github.io/perf-book/)Cited by:[§III\-C](https://arxiv.org/html/2610.23044#S3.SS3.p6.1),[§III\-C](https://arxiv.org/html/2610.23044#S3.SS3.p7.1)\.
- \[45\]I\. Bouzenia, P\. T\. Devanbu, and M\. Pradel\(2025\)RepairAgent: an autonomous, llm\-based agent for program repair\.In47th IEEE/ACM International Conference on Software Engineering, ICSE 2025, Ottawa, ON, Canada, April 26 \- May 6, 2025,pp\. 2188–2200\.External Links:[Link](https://doi.org/10.1109/ICSE55347.2025.00157),[Document](https://dx.doi.org/10.1109/ICSE55347.2025.00157)Cited by:[§V\-A](https://arxiv.org/html/2610.23044#S5.SS1.p3.1)\.
- \[46\]M\. Arnold, S\. J\. Fink, D\. Grove, M\. Hind, and P\. F\. Sweeney\(2005\)A survey of adaptive optimization in virtual machines\.Proceedings of the IEEE93\(2\),pp\. 449–466\.External Links:[Document](https://dx.doi.org/10.1109/JPROC.2004.840305)Cited by:[§V\-C1](https://arxiv.org/html/2610.23044#S5.SS3.SSS1.p1.1)\.
- \[47\]V\. Bala, E\. Duesterwald, and S\. Banerjia\(2000\)Dynamo: a transparent dynamic optimization system\.InProceedings of the 2000 ACM SIGPLAN Conference on Programming Language Design and Implementation \(PLDI\), Vancouver, Britith Columbia, Canada, June 18\-21, 2000,M\. S\. Lam \(Ed\.\),pp\. 1–12\.External Links:[Link](https://doi.org/10.1145/349299.349303),[Document](https://dx.doi.org/10.1145/349299.349303)Cited by:[§V\-C1](https://arxiv.org/html/2610.23044#S5.SS3.SSS1.p1.1)\.
- \[48\]G\. M\. Amdahl\(1967\)Validity of the single processor approach to achieving large scale computing capabilities\.InAmerican Federation of Information Processing Societies: Proceedings of the AFIPS ’67 Spring Joint Computer Conference, April 18\-20, 1967, Atlantic City, New Jersey, USA,AFIPS Conference Proceedings, Vol\.30,pp\. 483–485\.External Links:[Link](https://doi.org/10.1145/1465482.1465560),[Document](https://dx.doi.org/10.1145/1465482.1465560)Cited by:[§V\-C1](https://arxiv.org/html/2610.23044#S5.SS3.SSS1.p1.1)\.
- \[49\]R\. Allen and K\. Kennedy\(2001\)Optimizing compilers for modern architectures: A dependence\-based approach\.Morgan Kaufmann\.External Links:ISBN 1\-55860\-286\-0Cited by:[§V\-D](https://arxiv.org/html/2610.23044#S5.SS4.p2.1)\.
- \[50\]S\. S\. Muchnick\(1997\)Advanced compiler design and implementation\.Morgan Kaufmann\.External Links:ISBN 1\-55860\-320\-4Cited by:[§V\-D](https://arxiv.org/html/2610.23044#S5.SS4.p2.1)\.
- \[51\]The Rust Project Developers\(2026\)The Rust standard library\.External Links:[Link](https://doc.rust-lang.org/std/)Cited by:[§V\-D](https://arxiv.org/html/2610.23044#S5.SS4.p2.1)\.
- \[52\]Z\. Yuan, M\. Liu, S\. Ding, K\. Wang, Y\. Chen, X\. Peng, and Y\. Lou\(2024\)Evaluating and improving chatgpt for unit test generation\.Proc\. ACM Softw\. Eng\.1\(FSE\),pp\. 1703–1726\.External Links:[Link](https://doi.org/10.1145/3660783),[Document](https://dx.doi.org/10.1145/3660783)Cited by:[§V\-E](https://arxiv.org/html/2610.23044#S5.SS5.p2.1)\.
- \[53\]Z\. Gong, Z\. Chen, J\. J\. Szaday, D\. C\. Wong, Z\. Sura, N\. Watkinson, S\. Maleki, D\. A\. Padua, A\. V\. Veidenbaum, A\. Nicolau, and J\. Torrellas\(2018\)An empirical study of the effect of source\-level loop transformations on compiler stability\.Proc\. ACM Program\. Lang\.2\(OOPSLA\),pp\. 126:1–126:29\.External Links:[Link](https://doi.org/10.1145/3276496),[Document](https://dx.doi.org/10.1145/3276496)Cited by:[§V\-E](https://arxiv.org/html/2610.23044#S5.SS5.p3.1)\.
- \[54\]C\. Curtsinger and E\. D\. Berger\(2013\)STABILIZER: statistically sound performance evaluation\.InArchitectural Support for Programming Languages and Operating Systems, ASPLOS 2013, Houston, TX, USA, March 16\-20, 2013,V\. Sarkar and R\. Bodík \(Eds\.\),pp\. 219–228\.External Links:[Link](https://doi.org/10.1145/2451116.2451141),[Document](https://dx.doi.org/10.1145/2451116.2451141)Cited by:[§V\-E](https://arxiv.org/html/2610.23044#S5.SS5.p3.1)\.
- \[55\]openAIExternal Links:[Link](https://openai.com/)Cited by:[§VI\-A](https://arxiv.org/html/2610.23044#S6.SS1.p1.1)\.
- \[56\]OpenAI\(2026\)Codex cli\.Note:https://github\.com/openai/codexVersion 0\.153\.4, accessed 2026\-09\-08Cited by:[§VI\-A](https://arxiv.org/html/2610.23044#S6.SS1.p2.1)\.
- \[57\]R\. Pan, A\. R\. Ibrahimzada, R\. Krishna, D\. Sankar, L\. P\. Wassi, M\. Merler, B\. Sobolev, R\. Pavuluri, S\. Sinha, and R\. Jabbarvand\(2024\)Lost in translation: A study of bugs introduced by large language models while translating code\.InProceedings of the 46th IEEE/ACM International Conference on Software Engineering, ICSE 2024, Lisbon, Portugal, April 14\-20, 2024,pp\. 82:1–82:13\.External Links:[Link](https://doi.org/10.1145/3597503.3639226),[Document](https://dx.doi.org/10.1145/3597503.3639226)Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[58\]Z\. Yang, F\. Liu, Z\. Yu, J\. W\. Keung, J\. Li, S\. Liu, Y\. Hong, X\. Ma, and Z\. J\. andns Ge Li\(2024\)Exploring and unleashing the power of large language models in automated code translation\.Proc\. ACM Softw\. Eng\.1\(FSE\),pp\. 1585–1608\.External Links:[Link](https://doi.org/10.1145/3660778),[Document](https://dx.doi.org/10.1145/3660778)Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[59\]A\. R\. Ibrahimzada, K\. Ke, M\. Pawagi, M\. S\. Abid, R\. Pan, S\. Sinha, and R\. Jabbarvand\(2025\)AlphaTrans: A neuro\-symbolic compositional approach for repository\-level code translation and validation\.Proc\. ACM Softw\. Eng\.2\(FSE\),pp\. 2454–2476\.External Links:[Link](https://doi.org/10.1145/3729379),[Document](https://dx.doi.org/10.1145/3729379)Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[60\]Z\. Guan, X\. Yin, Z\. Peng, and C\. Ni\(2025\)RepoTransAgent: multi\-agent llm framework for repository\-aware code translation\.External Links:2508\.17720,[Link](https://arxiv.org/abs/2508.17720)Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[61\]H\. Zhang, C\. David, M\. Wang, B\. Paulsen, and D\. Kroening\(2024\)Scalable, validated code translation of entire projects using large language models\.CoRRabs/2412\.08035\.External Links:[Link](https://doi.org/10.48550/arXiv.2412.08035),[Document](https://dx.doi.org/10.48550/ARXIV.2412.08035),2412\.08035Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[62\]B\. Rozière, M\. Lachaux, L\. Chanussot, and G\. Lample\(2020\)Unsupervised translation of programming languages\.InAdvances in Neural Information Processing Systems 33: Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, December 6\-12, 2020, virtual,Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[63\]M\. Bhattarai, J\. E\. Santos, S\. Jones, A\. Biswas, B\. Alexandrov, and D\. O’Malley\(2024\)Enhancing code translation in language models with few\-shot learning via retrieval\-augmented generation\.In2024 IEEE High Performance Extreme Computing Conference \(HPEC\),Vol\.,pp\. 1–8\.External Links:[Document](https://dx.doi.org/10.1109/HPEC62836.2024.10938485)Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[64\]A\. Z\. H\. Yang, Y\. Takashima, B\. Paulsen, J\. Dodds, and D\. Kroening\(2024\)VERT: verified equivalent rust transpilation with few\-shot learning\.CoRRabs/2404\.18852\.External Links:[Link](https://doi.org/10.48550/arXiv.2404.18852),[Document](https://dx.doi.org/10.48550/ARXIV.2404.18852),2404\.18852Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[65\]V\. Nitin, R\. Krishna, L\. L\. do Valle, and B\. Ray\(2025\)C2SaferRust: transforming C projects into safer rust with neurosymbolic techniques\.CoRRabs/2501\.14257\.External Links:[Link](https://doi.org/10.48550/arXiv.2501.14257),[Document](https://dx.doi.org/10.48550/ARXIV.2501.14257),2501\.14257Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.
- \[66\]Corrode\(2017\)External Links:[Link](https://github.com/jameysharp/corrode)Cited by:[§IX](https://arxiv.org/html/2610.23044#S9.p1.1)\.