Rust Performance Engineering on Atharva Pandey

Lesson 12: Zero-Copy Parsing — bytes, nom, winnow

Sat, 12 Apr 2025 11:30:00 +0000

I once had to parse 2GB of log files per hour on a machine with 4GB of RAM. The naive approach — read line, split into fields, store as String — peaked at 6GB memory usage and fell over. The data was being duplicated everywhere: once in the read buffer, once in each split String, once in the output struct. Three copies of every byte.

The zero-copy version peaked at 2.1GB — basically the file size plus a thin layer of parsed references. Same output, same correctness, one-third the memory, twice the throughput. Zero-copy parsing is one of the most powerful techniques in Rust’s performance toolkit, and the ownership system makes it uniquely natural here.

Lesson 11: Binary Size Reduction — Smaller deployments

Mon, 07 Apr 2025 13:17:00 +0000

I shipped a “hello world” Rust binary to a team once and they came back confused: “Why is this 4 megabytes?” Fair question. A C hello-world is 16KB. A Go hello-world is about 2MB. A default Rust hello-world with standard linking is 3-4MB.

That 4MB isn’t wasted — it’s the Rust standard library, panic handling, formatting machinery, and debug symbols. But when you’re building container images, deploying to embedded devices, or targeting WebAssembly, every megabyte counts. Here’s how to cut Rust binaries down to size.

Lesson 10: Compile Time Optimization — Strategies that actually work

Thu, 03 Apr 2025 08:55:00 +0000

My main Rust project at work took 4 minutes and 38 seconds for a clean build. That was two years ago. Today it takes 52 seconds. Same codebase — more code, actually. Same hardware. The difference is about a dozen targeted changes, none of which involved rewriting application code.

Rust’s compile times are its most legitimate criticism. But “Rust is slow to compile” is the starting point, not the conclusion. Most projects can cut their build times by 50-80% with the right techniques. Let me show you what actually moves the needle.

Lesson 9: Inlining — #[inline] and LTO

Mon, 31 Mar 2025 19:05:00 +0000

A few years ago I was profiling a JSON parser and noticed something weird. A tiny function — four lines, no allocations — was showing up as a 15% hot spot. Not because it was slow, but because it was called 8 million times per second and the function call overhead (push registers, set up stack frame, call, pop registers, return) was eating 2 nanoseconds each call. That’s 16 milliseconds per second just in function prologues and epilogues.

Lesson 8: Cache-Friendly Data Structures — Data-oriented design

Sat, 29 Mar 2025 07:40:00 +0000

Here’s a number that should change how you think about data structures: reading from L1 cache takes about 1 nanosecond. Reading from main memory takes about 100 nanoseconds. That’s a 100x penalty for a cache miss. On a modern CPU running at 4 GHz, a single cache miss stalls the processor for roughly 400 cycles. Four hundred cycles where your CPU is sitting there, doing nothing, waiting for data to arrive from RAM.

Lesson 7: Choosing the Right Collection — It's not always Vec

Thu, 27 Mar 2025 15:22:00 +0000

A friend asked me to review their service that was doing “thousands of lookups per second” against a Vec of about 50,000 entries. Linear scan every time. They’d chosen Vec because “it’s the default” and hadn’t thought about it further. Swapping to a HashMap took the lookup from 12µs to 40ns. Three hundred times faster. From a one-line change.

Choosing the right collection is one of the highest-leverage performance decisions you can make, and it requires basically zero cleverness. Just know your access patterns.

Lesson 6: String Performance — SmartString, CompactStr, and when to care

Tue, 25 Mar 2025 11:50:00 +0000

I was building an in-memory index that stored about 2 million tag strings. Most were short — “rust”, “go”, “api”, “v2” — averaging 6 bytes. But each String carries 24 bytes of overhead (pointer + length + capacity) plus the heap allocation for the actual data. That’s 24 bytes of bookkeeping to store 6 bytes of useful information. Plus 2 million separate allocations hammering the allocator.

Switching to CompactStr cut memory usage by 60% and index-building time by 40%. Strings matter more than you think.

Lesson 5: Iterators vs Loops — Performance characteristics

Sun, 23 Mar 2025 09:12:00 +0000

When I first started writing Rust, I wrote everything as for loops. Old habits from C. Then someone on my team rewrote one of my loops as an iterator chain and I got annoyed — it looked “slower” to me. More function calls, closures, chaining. Obviously that’s more overhead, right?

I benchmarked it. Same performance. Down to the nanosecond. I looked at the assembly. Identical. That was the day I stopped assuming and started measuring.

Lesson 4: Reducing Allocations — Stack, arena, SmallVec

Fri, 21 Mar 2025 16:30:00 +0000

I profiled a Rust web service once and found it was allocating 47,000 times per request. Forty-seven thousand. Most were tiny — 16-byte strings, 3-element vectors, temporary buffers. Each individual allocation was fast (jemalloc is good), but 47,000 of them at ~30ns each is 1.4ms of pure allocator overhead. Per request. At 10K RPS that’s 14 seconds of CPU time per second, just asking the allocator for memory.

The fix took half a day and cut allocations to about 200 per request. Here’s everything I know about reducing allocations in Rust.

Lesson 3: Profiling — perf, flamegraph, samply

Wed, 19 Mar 2025 10:45:00 +0000

A colleague once asked me to look at a Rust service that was “slow.” They’d already spent a week trying to optimize the JSON parsing layer because “parsing is always the bottleneck.” I ran a profiler. Sixty-three percent of CPU time was spent in Drop implementations, deallocating thousands of small strings that were created and immediately discarded. The JSON parsing was 4% of runtime.

Profiling would’ve found that in five minutes. That’s why this lesson exists.

Lesson 2: Benchmarking with criterion and divan — Statistically rigorous benchmarks

Mon, 17 Mar 2025 14:18:00 +0000

Last year I reviewed a PR where someone claimed their new serialization code was “2x faster.” Their benchmark? std::time::Instant::now() called once before and once after. Single run. No warmup. No statistical analysis. The “2x speedup” was thermal throttling on the first run.

Benchmarking is harder than it looks. Let’s do it properly.

Why Naive Benchmarks Lie

Before we get into the tools, let me show you all the ways a naive benchmark can mislead you:

Lesson 1: Performance Philosophy — Measure, don't guess

Sat, 15 Mar 2025 08:32:00 +0000

I once spent three days rewriting a hot loop to avoid a single allocation per iteration. Hand-rolled a custom arena, eliminated two clones, even switched from HashMap to a hand-tuned open-addressing table. Benchmarked the result: 0.3% improvement. The actual bottleneck? A DNS lookup buried in a library call that I never bothered to profile.

Three days. Zero meaningful impact. That’s the lesson I want to start this entire course with.