Performance on

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 8: Avoiding Premature Optimization — Measure first, optimize never (usually)

Thu, 10 Apr 2025 00:00:00 +0000

I’ve spent time in this series showing you how to make Go programs faster — escape analysis, stack allocation, pre-sizing data structures, zero-copy string handling, benchmarking discipline, pprof profiling, CPU vs memory tradeoffs. Every technique is real and useful. And every single one of them has been misapplied, including by me, when applied before understanding whether they were needed. The last lesson isn’t another technique. It’s the discipline that makes all the other techniques worth using: measure first, understand where the actual cost is, and optimize only there.

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.

Lesson 7: CPU vs Memory Tradeoffs — Cache it or compute it, pick one

Thu, 20 Feb 2025 00:00:00 +0000

Every performance optimization ultimately makes the same trade: you’re giving up memory to gain CPU time, or giving up CPU time to reduce memory usage. There’s no free lunch. The skill isn’t knowing that the tradeoff exists — it’s knowing which side of it you’re on, and making the choice consciously rather than accidentally. I’ve optimized for memory when the bottleneck was CPU, and optimized for CPU when memory was the problem. Both directions are wrong when you pick them without data.

Lesson 6: pprof Deep Dive — CPU, memory, goroutine — read all three

Sun, 05 Jan 2025 00:00:00 +0000

When I first learned about pprof, I thought it was a single tool that told you “what’s slow.” It took me an embarrassingly long time to understand that it’s actually a family of profilers — CPU, heap, allocs, goroutine, mutex, block — each answering a completely different question. Reading one profile and ignoring the others is like diagnosing engine trouble by only checking the oil. You might find something. You’ll definitely miss something. The profilers are designed to work together, and once you start reading all three, performance diagnosis goes from guesswork to diagnosis.

Lesson 5: Benchmarking Done Right — testing.B is not what you think

Sun, 10 Nov 2024 00:00:00 +0000

Writing a Go benchmark feels simple. You drop Benchmark in front of a function name, loop from 0 to b.N, run go test -bench=., and get a number. The number feels authoritative. I spent about a year trusting benchmark numbers that were wrong — not wrong because of bugs, but wrong because of how the benchmark was written. The Go benchmark framework is excellent, but it has sharp edges that will mislead you until you learn to see them.

Lesson 4: String and Byte Conversions — The copy nobody sees

Wed, 25 Sep 2024 00:00:00 +0000

Go strings are immutable. Byte slices are mutable. Converting between them requires copying the data — every time, without exception, unless you use unsafe tricks you almost certainly shouldn’t. That sounds like a minor footnote, but it becomes a significant issue the moment you start handling large volumes of text: parsing HTTP requests, processing log lines, building JSON responses. I’ve watched a single string(b) call inside a tight loop add measurable latency to a production API, and the fix was two lines of code once I knew what to look for.

Lesson 3: Slice and Map Performance — The data structure tax

Tue, 20 Aug 2024 00:00:00 +0000

Slices and maps are so convenient in Go that it’s easy to forget they’re not free. They have hidden costs — in allocations, in CPU cache misses, in GC scanning time — that only become visible when you push them into a hot path and watch your benchmarks light up. I’ve been burned by both, sometimes in embarrassing ways, and building intuition for when those costs matter has saved me more than one production incident.

Lesson 2: Stack vs Heap Intuition — The allocation you didn't know you made

Tue, 16 Jul 2024 00:00:00 +0000

There’s a class of performance bugs in Go that doesn’t show up in code review, doesn’t trigger the race detector, and doesn’t cause test failures. It just makes your service slowly worse under load. The source is almost always the same: heap allocations happening in places you didn’t intend, turning what should be fast stack operations into GC-visible objects that pile up until the collector has to stop and clean them up. Building an intuition for when Go allocates on the heap versus the stack was one of the single highest-leverage things I did to improve the services I work on.

Lesson 1: Escape Analysis — Where your data lives matters more than how you write it

Thu, 20 Jun 2024 00:00:00 +0000

I spent the first two years of writing Go completely unaware that the compiler was making decisions about my code that I never asked for — and that those decisions were quietly shaping the performance profile of everything I shipped. Escape analysis is the mechanism behind all of it. Once I understood it, I started reading code differently. Not just “does this work?” but “where does this data live, and did I give the compiler a chance to put it somewhere fast?”