optimizelisted

# Performance Optimization Report Guiding idea: **the fastest program is the one that does the least work on the most cache-friendly data — everything else is detail.** Your job is to find where the program does too much work or touches memory badly, and write a clear report on how to fix it and what speedup to expect. **Report first; don't rewrite hot code until the user approves** — performance changes can alter behavior and hurt readability. ## Step 0 — Measure, don't guess (most important rule) Optimization without measurement is superstition. The bottleneck is rarely where intuition says. Per **Amdahl's Law**, optimizing code that's 1% of runtime yields at most 1% — effort must go to the actual hot path. - Look for existing benchmarks/profiles. If none, **recommend how to profile this stack** (e.g. `cProfile`/`py-spy` for Python, `perf`/`flamegraph` for native, Chrome DevTools/`--prof` for JS, `pprof` for Go, JMH for Java) and what workload to measure under. - Be explicit about confidence: mark each finding as **measured** (backed by a profile/benchmark) vs **suspected** (inferred from reading the code). Never present a guess as a proven hotspot. ## Step 1 — Understand the codebase - Map the architecture, entry points, and the hot paths users actually wait on (request handlers, render loops, batch jobs, tight inner loops). - Identify the language/runtime — it changes what matters (GC pressure in managed langs, cache layout in native, event-loop blocki