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

Zhiqiang Yuan; Chong Wang; Zhenhao Zhou; Junwei Liu; Xin Peng

cs.AIOct 16, 2026

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

Authors: Zhiqiang Yuan, Chong Wang, Zhenhao Zhou, Junwei Liu, Xin Peng

Organizations: Department of Computer Science, Fudan University, China · Nanyang Technological University, Singapore

Abstract

Rust is increasingly adopted as a memory-safe successor to C, and transpilers such as \crust{} can 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 their \crust{} translations. 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 present \ourtool{}, an LLM-based approach that encodes these issues as reusable optimization rules to recover the performance of translated Rust. \ourtool{} profiles 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, \ourtool{} preserves C outputs on all tested workloads and speeds up 40 operations over the \crust{} translations, 18 of which end up faster than the original C. It outperforms the general-purpose coding agent \codex{} on 31 of the 37 operations where both preserve C outputs, and outperforms its own variant without rule guidance on 34 of the 41 operations.

Figures & tables

Project	KLoC	Operations	Workload Inputs
libcsv	1.0	Parsing; Field escaping	67 MiB CSV ‡ ; 10K escaped fields ‡
libogg	2.9	Stream encoding; Decoding	300K / 30K packets (1 KiB each) ‡
xxHash	3.9	XXH64; XXH3; XXH32 hashing	64 KiB buffer ‡
libzahl	5.7	Multiplication; Long division; Modular exponentiation	4,096-bit factors ‡ ; 8,192/4,096-bit dividend/divisor ‡ ; 4,096-bit base/modulus and 256-bit exponent ‡
bzip2	5.9	Compression; Decompression	Silesia files † ( ${\sim}$ 100 MiB); Derived .bz2 files ‡ ( ${\sim}$ 24 MiB)
binn	6.4	Serialization; Deserialization	100K-element int32 list ‡

TABLE I: Projects and workloads in the Study and Evaluation Datasets.

Project	Operation ( $\Delta$ )	Project	Operation ( $\Delta$ )	Project	Operation ( $\Delta$ )
libcsv	Parsing $+35.1\%$	xxHash	XXH64 $-0.3\%$	binn	Serialization $+40.9\%$
	Field escaping $+8.3\%$		XXH3 $+33.1\%$		Deserialization $+27.9\%$
libogg	Stream encoding $+2.2\%$		XXH32 $+62.2\%$	json-c	Parsing $+1.9\%$
	Decoding $+0.2\%$	libzahl	Multiplication $+37.3\%$		Serialization $+2.8\%$
bzip2	Compression $+1.4\%$		Long division $-0.6\%$	heman	Distance-field $+27.6\%$
	Decompression $+15.5\%$		Modular exp. $+10.2\%$		Lighting $+29.5\%$

TABLE II: Runtime overhead (

\Delta

) after c2rust translation; positive values indicate slowdown over C.

Cost	Project	Operation	$\boldsymbol{R_{\mathrm{inst}}}$	$\boldsymbol{R_{\mathrm{CPI}}}$	Cost	Project	Operation	$\boldsymbol{R_{\mathrm{inst}}}$	$\boldsymbol{R_{\mathrm{CPI}}}$
Work	binn	Serialization	$1.530$	$0.921$	CPI	heman	Lighting	$0.935$	$1.391$
Work		Deserialization	$1.450$	$0.899$	CPI	libcsv	Field escaping	$0.994$	$1.089$
Work	bzip2	Decompression	$1.348$	$0.860$	Both	libcsv	Parsing	$1.267$	$1.067$
Work	heman	Terrain generation	$1.226$	$0.970$	Both	xxHash	XXH3	$1.270$	$1.052$
Work	libzahl	Modular exponentiation	$1.123$	$0.980$	Both	heman	Distance-field pipeline	$1.078$	$1.186$
CPI	xxHash	XXH32	$0.475$	$3.417$	Both	libzahl	Multiplication	$1.231$	$1.113$

TABLE III: Execution-cost decomposition of the 12 operations with runtime overhead above

3\%

. Cost denotes increased dynamic work ( Work ), increased CPI only ( CPI ), or both ( Both ).

Performance Issue	Definition	Observed Pattern	Optimization Direction
Residual Bounds Checks	Bounds checks remain even when established index-range invariants prove them unnecessary.	Loop invariants establish valid indices, but optimized Rust IR retains checks leading to panic_bounds_check that 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 Saturation	Saturating float-to-integer conversions remain even when range invariants prove them unnecessary.	Optimized Rust IR uses llvm.fptosi.sat or llvm.fptoui.sat for range-bounded operands, whereas C IR uses fptosi or fptoui .	Avoid unnecessary saturation with to_int_unchecked for finite operands whose values, truncated toward zero, fit the target integer type.
Missed Loop Vectorization	Loop 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 Inlining	Hot 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 Dispatch	Loops 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 Management	Repeated allocation or fixed-increment growth incurs avoidable heap-allocation overhead.	An internal buffer is repeatedly allocated and freed, or grows by fixed increments through realloc .	Reuse buffers to reduce allocations; reserve capacity upfront or use geometric growth to reduce reallocations.

TABLE IV: Recurring performance issues and optimization directions identified in the Study Dataset.

Fig. 2: Region-specific optimization prompt for the zrsh loop

Code Translation

Code translation converts programs between languages, frameworks, and representations while aiming to preserve behavior and sometimes improve safety or performance.

See all 42 papers

ENCRUST: Encapsulated Substitution and Agentic Refinement on a Live Scaffold for Safe C-to-Rust Translation
Apr 6, 2026Hohyun Sim, Hyeonjoong Cho, Ali Shokri +2Code Translation LLM-Based Program Synthesis
Korea University, South Korea · University of Houston, United States · State University of New York Korea, South Korea +1
Mostly Automatic Translation of Language Interpreters from C to Safe Rust
Jun 25, 2026Bo Wang, Brandon Paulsen, Joey Dodds +3Code Translation
National University of Singapore, Singapore · Amazon, USA
Fine-Tuning Qwen3-27B for C-to-Rust Code Translation: A Three-Stage Curriculum of Pretraining, Debugging-Aware SFT, and Task-Specific SFT
Aug 13, 2026Pu Zhao, Changdi Yang, Yixiao Chen +4Code Translation Code Generation
Northeastern University · EmbodyX Inc · Aibao LLC

Apr 6, 2026J/K move · Enter open · S save

ENCRUST: Encapsulated Substitution and Agentic Refinement on a Live Scaffold for Safe C-to-Rust Translation

Hohyun Sim, Hyeonjoong Cho, Ali Shokri, Zhoulai Fu+1

Korea University, South Korea · University of Houston, United States · State University of New York Korea, South Korea+1

Code Translation LLM-Based Program Synthesis

Open paper AskPDF arXiv

We present Encapsulated Substitution and Agentic Refinement on a Live Scaffold for Safe C-to-Rust Translation, a two-phase pipeline for translating real-world C projects to safe Rust. Existing approaches either produce unsafe output without memory-safety guarantees or translate functions in isolation, failing to detect cross-unit type mismatches or handle unsafe constructs requiring whole-program reasoning. Furthermore, function-level LLM pipelines require coordinated caller updates when type signatures change, while project-scale systems often fail to produce compilable output under real-world dependency complexity. Encrust addresses these limitations by decoupling boundary adaptation from function logic via an Application Binary Interface (ABI)-preserving wrapper pattern and validating each intermediate state against the integrated codebase. Phase 1 (Encapsulated Substitution) translates each function using an ABI-preserving wrapper that splits it into two components: a caller-transparent shim retaining the original raw-pointer signature, and a safe inner function targeted by the LLM with a clean, scope-limited prompt. This enables independent per-function type changes with automatic rollback on failure, without coordinated caller updates. A deterministic, type-directed wrapper elimination pass then removes wrappers after successful translation. Phase 2 (Agentic Refinement) resolves unsafe constructs beyond per-function scope, including static mut globals, skipped wrapper pairs, and failed translations, using an LLM agent operating on the whole codebase under a baseline-aware verification gate. We evaluate Encrust on 7 GNU Coreutils programs and 8 libraries from the Laertes benchmark, showing substantial unsafe-construct reduction across all 15 programs while maintaining full test-vector correctness.

Abstract

Code Translation

Explore similar work

ENCRUST: Encapsulated Substitution and Agentic Refinement on a Live Scaffold for Safe C-to-Rust Translation

Mostly Automatic Translation of Language Interpreters from C to Safe Rust

Fine-Tuning Qwen3-27B for C-to-Rust Code Translation: A Three-Stage Curriculum of Pretraining, Debugging-Aware SFT, and Task-Specific SFT