0
Interpret a flamegraph and turn it into a prioritized optimization list
⁂auto-checked, 4 days oldAauraNovice
The prompt
I'm pasting a description or text export of a CPU flamegraph / profiler output for service_name. Help me turn it into action, not just commentary:
1. Identify the widest frames (highest self-time, not just total time) and name the actual function/operation, not just 'this looks slow'.
2. For each of the top 3 hotspots, give a hypothesis for WHY it's expensive (algorithmic complexity, unnecessary allocation, serialization overhead, lock contention, N+1 pattern) based on the function names and call context I give you.
3. Rank the 3 by expected impact-to-effort ratio, not just raw self-time, factoring in whether the fix is a one-line change or a redesign.
4. For the top-ranked one, propose a concrete fix and estimate (rough order of magnitude, not precise) how much it should reduce that frame's cost.
5. Note any hotspot that's actually expected/acceptable (e.g. a crypto operation that's inherently expensive) so I don't waste time optimizing something that's already near-optimal.
Profiler output / description: profile_data
Language/runtime: language
Context (request volume, latency budget): context
Where it has been run
| Model | Version | People | Broke | Auto | Last |
|---|---|---|---|---|---|
| Claude | Haiku 4.5 | 0 | 0 | 1/1 | 4 days ago |
Example output
Top hotspot: `json.dumps` at 34% self-time inside `serialize_response`. Hypothesis: the response includes a large nested object that's being re-serialized on every request even when most of it is cached/unchanged data, classic redundant-serialization pattern.
Second: `re.match` at 18%, called inside a loop over every request header, likely because the regex is being recompiled per call instead of precompiled at module load.
Third: `db.query` connection acquisition at 11%, consistent with pool exhaustion under load rather than the query itself being slow.
Ranked by impact/effort: #2 first (one-line fix, compile the regex once at module scope, near-zero risk, should cut that frame close to zero), then #1 (cache the serialized static portion, moderate effort), then #3 (needs pool sizing investigation, higher effort, likely infra config not code).
Note: a `hashlib.sha256` frame at 6% is expected, that's the auth signature check and is already near-optimal, not worth touching.
0 comments
Sign in to comment or report what this prompt did for you.
Sign inNo comments yet. Run the prompt and report what you got.