rust-performancelisted

# Rust Performance **Evidence.** Identify the requested result: an audit, a measurement, or an optimization. Define the workload and the metric, and establish a comparable baseline before changing anything. Honor supplied requirements and preserve settled choices outside the requested change; resolve only what the task leaves open. Separate the properties, because they are different claims with different measurements: request latency percentiles, throughput under the in-flight limit, allocation rate, live heap and peak resident memory, startup time, and binary size. Measure a release build directly; a cargo run or a debug profile is not a comparable baseline. Keep toolchain, features, input, and environment fixed across samples, and retain the variance rather than rerunning until a favorable sample appears. In request paths, keep data moving: pass byte buffers and borrowed slices, stream bodies when the contract allows, and account for what each retained buffer, queue, and cached verdict holds as concurrency grows. The body limit, the in-flight limit, and the request timeout are the capacity model; an optimization that moves cost into an unbounded place is a regression. A clone on a hot path matters and a clone at startup does not. Treat link-time optimization, codegen units, the panic strategy, allocator changes, and profile-guided optimization as measured alternatives with named trade-offs. Aborting on panic disables the sanitized server error that panic recovery provid