89. cold_path — Tell the Compiler Which Branch Won't Happen
Your error-handling branch fires once in a million calls, but the compiler doesn’t know that. core::hint::cold_path lets you mark unlikely branches so the optimiser can focus on the hot path.
Why branch layout matters
Modern CPUs predict which way a branch will go and speculatively execute instructions ahead of time. When the prediction is right, execution flies. When it’s wrong, the pipeline stalls.
Compilers already try to guess which branches are hot, but they don’t always get it right — especially when both sides of an if look equally plausible from a static analysis perspective. That’s where cold_path comes in.
The basics
Call cold_path() at the start of a branch that is rarely taken:
| |
The compiler now knows the else arm is unlikely. It can lay out the machine code so the hot path (the Some arm) has no jumps, keeping it in the instruction cache and the branch predictor happy.
In match expressions
cold_path works well in match arms too — mark the rare variants:
| |
Only the branches you expect to be common stay on the fast track.
Building likely and unlikely helpers
If you’ve used C/C++, you might miss __builtin_expect. With cold_path you can build the same thing:
| |
Now you can annotate conditions directly instead of marking individual branches.
A word of caution
Misusing cold_path on a branch that actually runs often can hurt performance — the compiler will deprioritise it, and you’ll get more pipeline stalls, not fewer. Always benchmark before sprinkling hints around. Profile first, hint second.
The bottom line
cold_path is a zero-cost, zero-argument function that tells the optimiser what you already know: this branch is the exception, not the rule. It’s a small tool, but in hot loops and latency-sensitive code, it can make a measurable difference.
Stabilised in Rust 1.95 (April 2026).