Performance-Trace analysieren
Liest einen Performance-Trace (DevTools, flamegraph, profile.json) und priorisiert die lohnenden Optimierungen.
Zuletzt geprüft 23. April 2026
Prompt
Analyze this performance trace. Goal: identify the optimizations worth doing. Input: - Trace format: [CHROME DEVTOOLS / NODE PROFILE / PY-SPY / FLAMEGRAPH / CUSTOM] - Context: what the user did during the trace - Target: which metric to improve (load, interaction, server time, memory) Output: 1. TOP 3 HOT SPOTS - by self-time or cumulative, with % 2. FOR EACH HOT SPOT - what code / library / operation, why it's hot, one concrete optimization 3. LOW-HANGING FRUIT - cheap changes (caching, early return, lazy import) that might save 20%+ 4. NOT WORTH FIXING - hot spots that are structural (framework overhead, necessary computation) - name them so we don't chase them 5. MEASURE FIRST CHANGES - which fix has the biggest expected impact. Measure this one first before touching the others. Rules: - Do not propose a fix whose impact you can't estimate from the trace - Beware of Amdahl: fixing a 5% path wastes effort. Say so. - Do not recommend rewriting in a faster language as first suggestion - Memory optimizations: only if the trace shows GC/allocation issues; don't guess Trace: [PASTE RELEVANT SECTION] What I already tried: [OPTIONAL]
Wann nutzen
Wenn Profiling-Daten vorliegen und du den Hebel mit dem besten Kosten-Nutzen finden willst.
Use-Cases
- Seite lädt langsam, DevTools-Performance-Tab als Input.
- Node-Service p99 zu hoch, CPU-Profil liefert Daten.
- Mobile-App-Startup dauert zu lange.
Getestet mit
“Not worth fixing” ist oft der wichtigste Abschnitt - verhindert die klassische Optimierung an der falschen Stelle.