---
name: dev-performance-profiler
description: Diagnostic et optimisation des performances d'applications. Se déclenche avec "performance", "lent", "optimiser", "profiling", "memory leak", "CPU", "latence", "bottleneck", "mon app est lente", "temps de réponse".
---

# Performance Profiler

## Workflow
1. Identifier le symptôme (lenteur, haute CPU, memory leak, timeouts) — recueillir les métriques observées, les conditions de reproduction et l'environnement affecté (prod, staging, local).
2. Choisir l'outil de profiling adapté à la stack : dotTrace ou PerfView pour .NET, Chrome DevTools ou Clinic.js pour Node.js/JS, cProfile ou Py-Spy pour Python, async-profiler pour Java/JVM, perf ou pprof pour Go.
3. Profiling CPU : capturer les hot paths, identifier les algorithmes coûteux (O(n²), boucles imbriquées), repérer les appels redondants et les calculs inutiles dans les chemins critiques.
4. Profiling mémoire : analyser les allocations par type, mesurer la GC pressure (fréquence et durée des collections), détecter les memory leaks et l'object retention (références circulaires, event handlers non désabonnés).
5. Profiling I/O : diagnostiquer les requêtes DB (N+1 queries, full scans, missing indexes), les appels réseau synchrones bloquants, les accès fichiers non buffurisés et les mauvais usages async/await (deadlocks, sync-over-async).
6. Analyser les résultats : interpréter les flame graphs (largeur = temps CPU), les call trees (top-down vs bottom-up), les allocation reports et les timeline snapshots pour hiérarchiser les optimisations.
7. Appliquer les optimisations ciblées : caching (mémoire, distribué), batching des requêtes DB, lazy loading, connection pooling, remplacement d'algorithmes, index DB, parallelisation appropriée.
8. Benchmarker avant/après : mesurer l'impact précis avec BenchmarkDotNet (.NET), hyperfine (CLI), pytest-benchmark (Python), wrk/k6 (HTTP) ; documenter les gains et les régressions éventuelles.

## Règles
- Toujours mesurer avant d'optimiser : ne pas supposer, profiler d'abord pour trouver le vrai bottleneck.
- Adapter les outils à la stack de l'utilisateur (language, runtime, cloud vs on-prem).
- Proposer des solutions progressives : quick wins en premier, refactorings lourds ensuite.
- Fournir des commandes et configs prêtes à l'emploi, pas seulement des conseils généraux.
- Valider chaque optimisation par un benchmark avant/après pour éviter les régressions.


## Communication Rules — MANDATORY

- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.