performance-patterns

Start by confirming the loop is actually hot through its call context, then address factors in cost order: fix algorithmic complexity first, then allocations and redundant work. Verify claims with profiling tools like pprof or criterion before acting on memory or concurrency concerns.

Flag statically verifiable issues first: O(n²) patterns like linear search inside loops, allocations inside loops that could be hoisted, unbuffered I/O per item, and loop-invariant recomputation. Report cache and contention concerns as notes unless profiling data exists.

Use perf, valgrind cachegrind, or hyperfine for whole programs; Go pprof and benchstat; Rust criterion; and Zig poop or std.Io.Timestamp micro-benchmarks. For Go escape analysis, run go build -gcflags=-m to check claims statically.

Yes, version-gated APIs are checked against the project baseline from the build manifest, such as the go.mod directive, Cargo.toml edition, or build.zig.zon minimum_zig_version. Entries requiring newer versions are presented as upgrade-gated options rather than applied silently.

Avoid micro-optimizations in cold paths like initialization, error handling, and CLI parsing, where only egregious waste such as O(n²) growth warrants fixing. Never trade correctness, aliasing rules, or idiomatic allocations for speed.