Rust Performance and Layout
Use this when performance matters enough to justify design pressure.
Working stance
- Measure before changing shapes.
- Fix the largest hot-path cost, not the most obvious micro-optimization.
- Keep iterator pipelines lazy until you genuinely need a collection.
- Reuse allocations and tighten data movement before reaching for cleverness.
- Keep layout decisions explicit when they affect cache use or FFI.
- Prefer simple code unless profiling proves it is the bottleneck.
Decision surface
| Pressure | First move |
|---|---|
| repeated allocation | reuse buffers, pre-size collections |
| large enum or struct footprint | inspect layout, box rare large fields |
| string and byte churn | borrow or use slices/bytes where lifetimes allow |
| clone-heavy hot path | revisit ownership and API boundaries |
| "faster" rewrite with no numbers | benchmark first |
Red flags
- benchmarking starts after the rewrite,
- iterator chains collect into temporary
Vecs only to be filtered or walked again, - hot loops build strings with repeated
format!()calls, - index-based loops appear where iterators express the same walk clearly,
- tiny local wins complicate the API surface,
- hot-path code formats strings or allocates collections repeatedly,
- data layout changes happen without measuring access patterns,
- unsafe code is introduced before safe structural fixes are tried.
Read allocation-and-reuse.md,
data-layout.md,
benchmark-discipline.md, and
rigorous-benchmarking.md for the
common forks. The last covers paired benchmarking (Tango), deterministic
profiling (iai-callgrind), open-versus-closed load models, tail latency
and goodput.
Source: leynos/rust-skill — distributed by TomeVault.