PerfR turns recurring C-to-Rust slowdowns into reusable rules
Where Does the Performance Go? Understanding and Recovering Performance Regressions in C-to-Rust Translation · arXiv:2610.23044
In plain words
The paper studies why software translated from C into Rust can run more slowly. PerfR is a rule-guided optimization framework: it profiles translated code to locate hot functions, matches recurring slowdown patterns within them, and uses an AI language model to assess and propose rewrites.
The model checks whether a rewrite's conditions hold; PerfR keeps a candidate only if tests show matching outputs and better runtime. On separate projects, PerfR ran faster than the unmodified translation on nearly every tested task and matched the original C outputs across the tasks tested.
The research
When software is mechanically translated from C into Rust, does its speed carry over, and if not, can the causes become fixes that also help on other projects?
The authors examine this using complete program tasks with checkable outputs, then reserve a disjoint set of projects to see whether the framework works beyond the projects used to derive its rules.
PerfR turns recurring slowdowns into rules for rewriting hot code in Rust translated from C, checking each change before keeping it.
Paired runs found translated Rust over 3% slower relative to C's runtime on 12 of 19 study tasks. Compiler and source analysis exposed nine recurring issues for PerfR's rewrite rules.
Across 41 tasks in 12 disjoint evaluation projects, PerfR ran faster than unmodified translated Rust on 40 and matched C's outputs on all 41. These task counts support performance recovery on the tested workloads.
The results cover selected, deterministic program tasks in 20 chosen projects; matching C outputs on tested inputs does not establish behavior on other inputs or tasks.
The initial C-to-Rust comparison also uses different language-specific build configurations, so it does not isolate translation from compiler and language effects.
What the evidence shows
- The question and test set
PerfR is a rule-guided optimization framework that uses a large language model (LLM) to improve Rust projects translated from C by c2rust, a C-to-Rust translator. The paper asks whether translation slows real projects, what causes the loss, and whether recurring causes can become reusable fixes.
It uses complete program tasks with checkable outputs, deriving rules from eight selected projects and evaluating them on 12 disjoint projects.
- Where translation slows
On the 19 study tasks, paired runs showed translated Rust was more than 3% slower than C on 12, with overhead measured relative to C's runtime. This makes clear the problem varies by task rather than showing one project-wide loss.
The authors then focus on project-owned hot functions from the slower tasks to trace the difference.
- From differences to rules
Comparing paired compiler outputs and translated source, the authors identify nine recurring issues: two forms of residual runtime work, two missed compiler transformations, and five source-level patterns. A candidate must be supported by workload and mechanism evidence; groups need at least three instances.
This turns observed code differences into optimization directions rather than treating any unusual-looking Rust as a performance issue.
- How PerfR applies them
PerfR applies those directions by profiling projects to find hot functions, matching Rust-side compiler artifacts and source against rules, and having the LLM check rewrite preconditions in project context.
It proposes a change after a pattern matches; functional checks and runtime measurements determine whether the change is kept.
- Runtime and behavior
On 41 tasks in the 12 disjoint evaluation projects, evaluators found lower runtime than unmodified translated Rust on 40; PerfR's outputs matched C on all 41 tested tasks. These are task counts, not an average speedup.
The runtime and output results support recovery on this selected workload set under the same evaluation workloads and setup.
- Rule contribution and reach
Two further checks address whether the rules matter and recur elsewhere. Starting from a shared refined baseline, PerfR was faster than the version omitting optimization cards on 34 of 41 tasks, supporting rule guidance in this pipeline.
On the disjoint evaluation projects, at least one rule pattern appeared in 94% of hot functions; that match rate indicates recognizable patterns, not accepted rewrites.
Deep
- Original paper authors
- Zhiqiang Yuan, Chong Wang, Zhenhao Zhou, Junwei Liu, Xin Peng
- Submitted to arXiv
- License
- arXiv non-exclusive