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.