Jump to content

Rust vs C++: Performance Benchmarks That Surprised Me

From JOHNWICK
Revision as of 04:38, 14 November 2025 by PC (talk | contribs) (Created page with "After two years of writing production code in both languages, I decided to settle the debate with real numbers. The internet is full of opinions about Rust versus C++. Most of them are based on theory, biased benchmarks, or tribal loyalty to one language over the other. I’ve been writing C++ professionally for eight years and Rust for the past two. Last month, I decided to stop arguing and start measuring. I built the same application in both languages — a high-perfo...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

After two years of writing production code in both languages, I decided to settle the debate with real numbers. The internet is full of opinions about Rust versus C++. Most of them are based on theory, biased benchmarks, or tribal loyalty to one language over the other. I’ve been writing C++ professionally for eight years and Rust for the past two. Last month, I decided to stop arguing and start measuring. I built the same application in both languages — a high-performance JSON parser with custom memory allocation — and ran comprehensive benchmarks across different workloads. The results challenged several assumptions I had about both languages.

What I Actually Tested Before diving into results, here’s exactly what I measured to keep this honest: The Application: A streaming JSON parser that processes log files ranging from 10MB to 10GB. Real-world scenario — parsing server logs for analytics. The Hardware:

  • AMD Ryzen 9 5950X (16 cores, 32 threads)
  • 64GB DDR4–3600 RAM
  • NVMe SSD with 7000MB/s read speed
  • Ubuntu 22.04 LTS

The Implementations:

  • C++20 with GCC 12.2, -O3 optimization, custom allocators
  • Rust 1.75 with cargo release profile, similar allocation strategy

I ran each test 50 times and took the median to eliminate outliers. Both implementations use the same algorithms — no tricks, no handicapping either language.

Benchmark 1: Raw Parsing Speed Task: Parse a 1GB JSON file containing 2 million log entries. Results:

  • C++: 2.43 seconds (average)
  • Rust: 2.51 seconds (average)

Winner: C++ by 3.3% This surprised me. I expected Rust to be slower due to bounds checking, but the difference is negligible. For context, 3.3% means if C++ processes 1000 requests, Rust processes 967. In production, network latency dwarfs this difference. The interesting part? Rust’s safety checks didn’t cost as much as I thought. LLVM optimizes away most bounds checks when it can prove they’re unnecessary.

Benchmark 2: Memory Allocation Patterns Task: Parse 10,000 small JSON objects (1–5KB each) with frequent allocations and deallocations. Results:

  • C++: 847ms (average)
  • Rust: 763ms (average)

Winner: Rust by 11% This one shocked me. Rust was noticeably faster when dealing with lots of small allocations. After profiling, I found why: Rust’s allocator (jemalloc on Linux) handles small allocations more efficiently than the default glibc allocator I was using in C++. When I switched C++ to also use jemalloc, the gap closed to 4%. Lesson: Allocator choice matters more than language choice for allocation-heavy workloads.

Benchmark 3: Multi-threaded Parsing Task: Parse 8 separate 500MB JSON files concurrently using 8 threads. Results:

  • C++: 1.89 seconds (average)
  • Rust: 1.76 seconds (average)

Winner: Rust by 7.4% Here’s where Rust’s design philosophy showed its strength. The Rust version was faster to write AND faster to run. Why? In C++, I spent hours debugging race conditions with shared state. Even with experience, I introduced two data races that only showed up under high load. The final C++ code uses mutexes conservatively — probably more than necessary — because I wanted to be sure it was correct. Rust wouldn’t compile with data races. The borrow checker forced me to design a better concurrent architecture upfront. The final Rust code uses lock-free message passing between threads, which turned out to be both safer and faster.

Benchmark 4: Memory Usage Task: Peak memory consumption while parsing a 5GB JSON file. Results:

  • C++: 847MB peak RAM
  • Rust: 834MB peak RAM

Winner: Rust by 1.5% Essentially identical. Both languages give you low-level control over memory, and I used similar strategies in both implementations. The difference? In C++, I had to be paranoid about every allocation and deallocation. In Rust, the compiler enforced memory safety, so I could focus on performance instead of correctness.

Benchmark 5: Binary Size Task: Size of the compiled executable with optimizations. Results:

  • C++: 2.1MB (stripped)
  • Rust: 3.4MB (stripped)

Winner: C++ by 38% Rust binaries are larger. This is partly due to statically linking the standard library and partly due to monomorphization (Rust generates a separate copy of generic functions for each type). For most applications, an extra 1.3MB doesn’t matter. For embedded systems or containers where every megabyte counts, C++ has an advantage.

Benchmark 6: Compile Time Task: Clean build time from source. Results:

  • C++: 8.7 seconds
  • Rust: 47.3 seconds

Winner: C++ by 444% Rust’s compilation is painfully slow. This is Rust’s biggest practical weakness. During development, incremental compilation helps, but clean builds take forever. Why? Rust does more work at compile time — borrow checking, trait resolution, extensive optimization. You’re trading compile time for runtime safety and performance. For large projects, Rust’s compile times can be a serious productivity hit.

The Surprise: Real-World Performance Here’s what mattered most in my production testing: I deployed both versions to handle live traffic for one week (50–50 split). Same servers, same load, same conditions. Bugs Found:

  • C++ version: 3 segmentation faults, 1 memory leak, 1 race condition
  • Rust version: 0 runtime crashes

P99 Latency (time to parse a typical 50KB log entry):

  • C++: 23ms
  • Rust: 21ms

Developer Velocity:

  • C++ version: 6 days to write, 3 days debugging production issues
  • Rust version: 8 days to write, 0 days debugging production issues

The Rust version was slightly slower to develop initially but saved days of debugging. In production, it was more reliable and marginally faster.

What This Means for Your Project After running these benchmarks, here’s my honest advice: Choose C++ if:

  • You’re working on an existing C++ codebase (rewriting is expensive)
  • Binary size really matters (embedded systems, minimal containers)
  • You need faster compile times for massive codebases
  • Your team has deep C++ expertise and good practices
  • You’re doing low-level systems work that requires specific C++ libraries

Choose Rust if:

  • You’re starting a new project from scratch
  • Memory safety bugs are expensive (financial systems, security-critical code)
  • You’re building concurrent systems (Rust makes this dramatically easier)
  • Developer time is more valuable than raw performance
  • You want to move fast without breaking things

The Honest Truth: For most applications, both languages are fast enough. The difference between 2.43s and 2.51s doesn’t matter when your database query takes 500ms. What matters is developer productivity and code reliability. Rust lets you move faster with more confidence. C++ gives you total control but requires constant vigilance.

The Myth of “Rewrite It in Rust” Based on these benchmarks, I’m skeptical of rewrites. If you have a working C++ application, rewriting it in Rust probably won’t give you meaningful performance gains. The case for Rust isn’t speed — it’s safety and maintainability. If your C++ codebase is riddled with memory bugs or you spend weeks debugging concurrency issues, then Rust makes sense. But if your C++ code works well and you have experienced developers maintaining it, stick with C++. The migration cost isn’t worth a 3% speedup.

My Personal Decision I’m writing all new projects in Rust. Not because it’s faster (it’s roughly the same speed), but because:

  • I ship features faster without worrying about memory bugs
  • I sleep better knowing the code won’t segfault in production
  • Refactoring is fearless because the compiler catches mistakes
  • Junior developers are more productive because Rust prevents entire classes of bugs

For existing C++ projects, I’m staying in C++. The investment in those codebases is too large to justify a rewrite.

Methodology Notes For those who want to reproduce these benchmarks:

  • All source code is available on my GitHub (link in bio)
  • I used identical algorithms — no language-specific optimizations
  • Both versions use minimal dependencies (no heavyweight frameworks)
  • I ran tests on dedicated hardware with no background processes
  • Statistical significance tested with Mann-Whitney U test (p < 0.05)

I’m not claiming these benchmarks represent every use case. Your mileage will vary based on your specific workload.

The Bottom Line Rust and C++ are both incredibly fast. The performance difference in most real-world applications is negligible — typically under 5%. The real difference is developer experience. Rust prevents you from making mistakes. C++ trusts you to do the right thing (and punishes you when you don’t). After two years of Rust and eight years of C++, I prefer writing Rust. But I respect C++ and understand why many teams stick with it. Choose the language that matches your team’s strengths and your project’s constraints. Ignore the tribalism. Both languages are excellent tools.