Rust performance study measures safety costs against C++ benchmarks

Rust developers keep arguing over the same promise: zero-cost abstractions. At C++ Russia 2026, Yury Gribov and Zakhar Akimov answered that debate with a benchmark-heavy talk that did not settle for slogans. Their “Rust Performance” session compared regular Rust against a patched toolchain with safety checks disabled, then measured where the language’s defaults hold up and where they leave visible overhead.

The talk ran May 16 from 01:45 to 02:45 in the RU track at the Moscow conference, which was organized by JUG Ru Group and billed as a gathering of 40 speakers, 35 talks, 10 partners and 600 participants. The timing fit the room’s appetite for performance arguments. The same deck later circulated widely among systems programmers, along with the repo and supporting material.

The authors built their baseline on Rust 1.87.0 and then modified the compiler to turn off runtime safety checks. They also disabled hashtable randomization and forced function alignment to keep measurements stable. That setup let them separate the cost of Rust’s safety machinery from the parts of the language that are still effectively free, including move semantics and static dispatch.

The benchmark set was broad enough to speak to everyday Rust work rather than one toy workload. It included Bevy and Veloren from gamedev, SpacetimeDB and Zed from infrastructure-heavy applications, and tools and libraries such as Ruff, regex, rav1e, oxipng, nalgebra, tokio and uv. The point was not just to see whether Rust could keep pace with C++, but to find which idiomatic patterns mattered in practice and which performance fears were really cargo cult.

That question drew interest before the conference, when Gribov posted the slides for review on the Rust forum on April 5, along with analysis materials, code examples, LLVM plugins, prooflinks and the benchmarking framework. The discussion quickly turned nuanced. One commenter pointed to an outstanding compiler issue in MaybeUninit::uninit, where a large array can be zero-initialized unexpectedly, a reminder that the gap between language guarantees and machine behavior is exactly where these performance debates live.

The broader Rust Project context makes the talk land harder. In June 2025, Rust’s compiler performance team launched its first build-performance survey because long compile times had become a major complaint, and it eventually drew more than 3,700 responses. Runtime speed is still the headline, but this talk showed why the community keeps widening the lens: the real question is not whether Rust is “slow,” but when its safety costs are measurable, when they are not, and what that means for the code people actually ship.