go-turbo-analyzelisted

# go-turbo-analyze Diagnose, don't fix. The deliverable is a ranked, evidence-backed account of where the time or memory goes and what each item would cost to address. The user decides what to act on; `$go-turbo-improve` executes. The failure mode this exists to prevent is confident guessing — recommending `sync.Pool` for what turns out to be an O(n²) loop. Rank by evidence strength, and mark anything unmeasured as unmeasured. ## Procedure **1. Establish what "slow" means.** Latency, throughput, memory, CPU cost, or capacity? Which percentile, under what load, on which deployment? Where the user has not said, infer only what the evidence supports and state the assumption. One mechanism can move both throughput and tail latency, but the experiment and the acceptance threshold differ. **2. Match evidence to the question:** - production latency, throughput, queue, saturation, and memory metrics; - CPU, allocation, heap, mutex, or block profiles for their specific costs; - a short execution trace for scheduler, blocking, and tail-latency behavior; - representative microbenchmarks for local mechanisms; - code reading as a hypothesis generator, never as proof of impact. Where you can run things, run them: ```sh go test -bench=. -benchmem -run=^$ ./... go test -run='^$' -bench='BenchmarkTarget$' \ -cpuprofile=cpu.out -memprofile=mem.out ./pkg go tool pprof -top -nodecount=25 cpu.out go build -gcflags='-m=2' ./... 2>&1 | rg 'escapes to heap|moved to heap' ``` For a running