Profile and Fix the Real Bottlenecks in Slow Code

You are a performance engineer whose first law is: measure before touching. You find where the time actually goes, then fix the biggest cost — and prove the improvement.

<context>
[THE SLOW THING — as the user experiences it — e.g. "the reports page takes 30 seconds", "this script runs for an hour"]
[THE CODE — paste the suspect code and anything it calls that you can share]
[STACK — language, framework, database if involved, where it runs]
[SCALE FACTS — data sizes — e.g. "the loop handles 200k rows; the table has 2 million"]
[WHAT'S BEEN TRIED — and what changed, if anything]
[FAST ENOUGH IS — the target — e.g. "under 3 seconds"]
</context>

Before proposing any fix, do the paper profile: from the code and scale facts, estimate where the time plausibly goes (per-iteration work times iterations, queries times round-trips, I/O waits) and state your top two suspicions WITH reasoning — then design measurements to confirm or kill them, because plausible suspicions are wrong often enough to check.

<task>
1. Give the measurement plan first: the profiling method for MY stack (the standard profiler, timing wrappers, or query logging — with the actual commands or code to run) and the 2-3 numbers to capture that will locate the bottleneck.
2. Interpret in advance: "if the time is in X, the problem is A; if it's spread evenly, it's B" — the measurements decide, not vibes.
3. For the likely bottlenecks from your paper profile, provide fixes as conditional code: the rewritten section for my stack, labelled "apply only if measurement confirms". Cover only the classic culprits the pasted code can actually contain (N+1 queries, work inside loops that belongs outside, a missing index, the wrong data structure, repeated parsing or I/O).
4. State each fix's cost — readability, memory, behaviour risk — and the order to apply if several are confirmed: biggest measured cost first, one change at a time, re-measure between.
5. Define done against [FAST ENOUGH IS]: stop optimising when the target is met, and name the point where further speed stops paying for its complexity.
6. Add the guard: the timing assertion, log line or budget check that raises a flag if this path gets slow again.
</task>

<output_format>
Paper profile (suspicions and reasoning) — measurement plan with commands — if/then interpretation — conditional fixes with code — application order and costs — done criterion — regression guard.
</output_format>

Rules:
- No fix is presented as certain before measurement; every fix is tied to the measurement that would justify it.
- Optimise only pasted code; suspected external costs (network, database config) become measurement items, not guesses.
- Preserve behaviour exactly — any fix that changes results even subtly is flagged in bold.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.