Communitygithub.com

wieslawsoltes/Performance-Skill

Plattformübergreifende .NET-Performance-Engineering-Fertigkeit für Coding-Agents, die CPU, Speicher, GC, Benchmarking, Parallelität, Startverhalten, natives Profiling, GPU-Rendering und Produktionsdiagnose auf macOS, Windows und Linux abdeckt.

Was ist Performance-Skill?

Diese Fertigkeit befähigt Coding-Agents, systematische Performance-Untersuchungen für jede .NET-Anwendung durchzuführen – von ASP.NET Core und Diensten über Desktop-Frameworks wie Avalonia, WPF, MAUI bis hin zu GPU-lastigen Grafikanwendungen, Spielen und NativeAOT- sowie nativen Interoperabilitätsworkloads. Sie etabliert unverhandelbare Regeln: Profiling und Benchmarking erfolgen stets auf optimierten Release-Builds unter realistischen Bedingungen; der Zustand von Commit, SDK, Laufzeitumgebung, Betriebssystem, Hardware und Toolversionen wird dokumentiert; kalter Start, Warmlauf, stationärer Zustand, Überlast und Herunterfahren werden getrennt betrachtet. Die Fertigkeit liefert eine strukturierte Berichtsvorlage mit Symptom, Reproduktion, Sammlung von Artefakten, Beweisen für die Ursache, dominante Ursache, kleinstmögliche und hochwirksame Lösung sowie Validierung durch äquivalente Vorher-Nachher-Läufe. Der Agent folgt einer Referenzroute, die über Indexdokumente zu Runtime, Speicher, Latenz, Startverhalten, Benchmarking, Produktion und GPU führt, und lädt nur die minimal nötigen Quellen für die aktuelle Hypothese, ohne an Zuständigkeitsgrenzen zu stoppen. Die Fertigkeit definiert außerdem Eigentumstests (z.B. hohe CPU bei verwalteten Stacks vs. hohe CPU unter P/Invoke, steigendes RSS bei stabilem verwalteten Heap) und eine Schnelltriage-Sequenz, die den Agenten in 12 Schritten vom Bau der produktionsäquivalenten Konfiguration bis zur Veröffentlichung von Median, Streuung, Ausreißern und Rohartefakten führt. Sie enthält eine umfangreiche Liste ungültiger Schlussfolgerungen, die der Agent ablehnen muss (z.B. „CPU ist hoch, also ist Methode X langsam“ ohne Stacks, oder „Viel GPU-Auslastung, also ist Shader X der Engpass“). Die Fertigkeit setzt auf aktuelle offizielle Referenzen und stellt sicher, dass Verbesserungen niemals ohne Vorher-Nachher-Beweise aus äquivalenten Workloads behauptet werden.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
Part ofDesign & UI
npx skills add wieslawsoltes/Performance-Skill
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

.NET Performance Engineering

Verwende diese Fertigkeit, wenn du die Leistung einer .NET-Anwendung untersuchst, erklärst, behebst, benchmarkst oder validierst – einschließlich ASP.NET Core, Dienste, Konsolenanwendungen, Avalonia, WPF, WinUI, MAUI, Skia, WebGPU, Spiel-/Grafik-Engines, NativeAOT und native Interoperabilitäts-Workloads.

Dieses Repository definiert eine Fertigkeit. SKILL.md ist der Richtlinien- und Routing-Einstiegspunkt; detaillierte operative Verfahren befinden sich in einer hierarchischen Referenzbaumstruktur. Lade nur die Indexe und Kapitel, die für die aktuelle Untersuchung erforderlich sind, und erweitere sie, wenn Beweise eine Zuständigkeitsgrenze überschreiten.

Unverhandelbare Regeln

  • Profile und benchmarke einen optimierten Build, normalerweise Release, in der tatsächlichen Bereitstellungsform.
  • Dokumentiere Commit und Dirty State, SDK/Runtime, Betriebssystem, Architektur, Hardware, Energiesparmodus, Workload, Tool-Versionen, Umgebungsüberschreibungen und genaue Befehle.
  • Stelle eine deterministische Reproduktion sicher, bevor du Code änderst.
  • Trenne Kaltstart, erste Nutzung, warmen stationären Zustand, Überlast, Drain und Herunterfahren.
  • Wärme stufenweise Kompilierung, Shader, Pipelines, Caches und Pools auf, es sei denn, das Kaltstartverhalten ist das Thema.
  • Sammle Beweise an jeder relevanten Zuständigkeitsgrenze: verwaltete Laufzeit, native Bibliothek, Kernel, Scheduler, Dateisystem/Netzwerk, Abhängigkeit, Treiber, GPU, Compositor und Display.
  • Schließe nicht allein aus RSS auf verwaltete Retention.
  • Schließe nicht allein aus hoher Framezeit, GPU-API-Nutzung oder Auslastung auf GPU-Sättigung.
  • Behaupte keine Behebung basierend auf einem Durchschnitt, einem Trace, einem Frame-Capture, einem Mikrobenchmark oder dem schnellsten Benchmark-Durchlauf.
  • Bewahre rohe Artefakte auf und melde fehlende Symbole, fallengelassene Ereignisse, Profiler-Overhead, Umgebungsvarianz und Unsicherheit.
  • Schütze Geheimnisse und personenbezogene Daten in Dumps, Traces, Logs, SQL-Spannen, Paketerfassungen und Benchmark-Eingabekorpora.
  • Behandle Befehlsbeispiele als versionssensitiv. Frage zuerst die installierte Hilfefunktion des Tools ab; sie überschreibt Beispiele, wenn die Syntax abweicht. Verwende references/command-reference.md für verifizierte Auswahlregeln und kanonische Formen.1

Erforderlicher Untersuchungsbericht

Berichte:

  1. Symptom – beobachtbare Auswirkung und verletztes Ziel.
  2. Reproduktion – deterministischer Workload und Umgebung.
  3. Sammlung – genaue Tools, Befehle, Dauer und Artefaktpfade.
  4. Beweise – Zähler, Traces, Captures, Dumps, Benchmark-Verteilungen und Messungen.
  5. Eigentümerschaft – verwaltete CPU, Runtime, native CPU, Kernel, Scheduler, I/O, Abhängigkeit, Speicher, Treiber, GPU, Compositor oder Display.
  6. Dominante Ursache – größte unterstützte Kosten, Wartezeit oder am schnellsten wachsende Ressource.
  7. Behebung – kleinste hochwirksame Code- oder Konfigurationsänderung.
  8. Validierung – äquivalente Vorher/Nachher-Läufe mit Streuungs- und Ausreißermetriken.
  9. Restrisiken – ungelöste Engpässe und Messgrenzen.

Behaupte niemals eine Verbesserung ohne Vorher-Nachher-Beweise aus einem äquivalenten Workload.

Referenz-Router

Beginne immer mit references/index.md, references/core/index.md und dem verifizierten references/command-reference.md.

Lade zusätzliche Domänenindexe je nach Fragestellung:

Lade jede relevante Plattformreferenz über references/platforms/index.md. Eine Einzelsystem-Untersuchung benötigt normalerweise ein Plattformdokument; plattformübergreifende Vergleiche und Remote-/Client-Server-Szenarien können mehrere erfordern.

Lade nicht standardmäßig jedes Dokument. Wähle die minimale Menge, die die aktuelle Hypothese beantwortet, aber stoppe nicht an einer Zuständigkeitsgrenze, nur weil eine andere Anleitung erforderlich ist.

Schnelltriage-Sequenz

  1. Baue und führe die produktionsäquivalente Konfiguration aus.
  2. Definiere Workload-Phasen, Erfolgsmetriken und eine Abbruchregel.
  3. Zeichne System.Runtime-Zähler sowie Prozess-CPU und Gesamtspeicher auf.
  4. Erfasse verwaltete CPU/Runtime-Beweise mit dotnet-trace, wenn verwaltete Eigentümerschaft plausibel ist.
  5. Erfasse wiederholte Stacks, wenn Fortschritt, Mangel oder Blockierung vermutet wird.
  6. Wenn die Gesamtkosten unerklärt sind, sammle den plattformnativen CPU-/Scheduler-/I/O-/Speicher-Trace.
  7. Bei Speicher vergleiche verwaltete Live-Bytes, GC-Belegung, private/RSS/PSS, native Allokationen, Mappings, Grafikallokationen und GPU-Residenz.
  8. Beim Rendern korreliere Anwendungsmarker, CPU-Übergabe, GPU-Zeitstempel, natives GPU-Capture, Present, Compositor und Display-Timing.
  9. Bei Benchmark-Anfragen wähle Mikro-, Komponenten-, Makro-, Last- oder Soak-Methodik, bevor du BenchmarkDotNet oder ein anderes Testsystem auswählst.
  10. Bei reinen Produktionsvorfällen verwende begrenzte oder ausgelöste Sammlung und zeichne cgroup/Host-Einschränkungen auf.
  11. Implementiere erst, nachdem Beweise die dominante Ursache stützen.
  12. Wiederhole den identischen Workload und veröffentliche Median, Streuung, Ausreißerwerte und rohe Artefakte.

Eigentumstests

  • Hohe Prozess-CPU mit heißen verwalteten Stacks: Anwendungs-/JIT-/Runtime-Arbeit.
  • Hohe Prozess-CPU unter P/Invoke: native Bibliothek, Allokator, Grafik-API oder Treiber-CPU.
  • Niedrige CPU mit wiederholten blockierten Stacks: Synchronisation, I/O, Scheduler, Warteschlangen oder externe Abhängigkeit.
  • Steigende ThreadPool-Warteschlange bei niedriger CPU und blockierten Stacks: Mangel oder Sync-over-Async.
  • Stabile verwaltete Live-Bytes bei wachsendem private/RSS: nativer Heap, Mappings, Code-Heaps, Fragmentierung, Grafikressourcen oder OS-Caches.
  • Wachsender verwalteter Live-Graph nach äquivalenten Vollcollection-Punkten: verwaltete Retention oder absichtlich unbegrenzter Cache.
  • Langer CPU-Frame mit kurzen GPU-Zeitstempeln: Anwendungs-/Render-Thread-/Treiber-CPU-gebunden.
  • Kurze CPU-Übergabe mit langen GPU-Zeitstempeln: GPU-Ausführungs-gebunden.
  • CPU und GPU frühzeitig abgeschlossen, aber Present ist spät: Swapchain, Compositor, V-Sync, Drawable-Mangel oder Display-Taktung.
  • GPU-Leerlauflücken zwischen abhängigen Übergaben: CPU-Mangel, übermäßige Synchronisation, Serialisierung oder unzureichende Pufferung.
  • Hohe Latenz bei niedriger On-CPU-Zeit: Off-CPU-Warten, Warteschlangen, Abhängigkeit, Drosselung oder Scheduler-Verzögerung.
  • Start verbessert sich, aber erste Aktion verschlechtert sich: Arbeit wurde verschoben, nicht entfernt.
  • Benchmark verbessert sich, aber die Produktmetrik nicht: Das Experiment ließ den kritischen Pfad aus, verwendete die falsche Eingabeverteilung oder optimierte eine nicht-dominante Operation.

Agenten-Arbeitsweise

  • Untersuche Build-, Bereitstellungs-, Diagnose-, Benchmark-Projekte, Eingabekorpora, CI und Artefakt-Konventionen des Repositorys.
  • Erstelle artifacts/performance/<issue-oder-zeitstempel>/ oder das Repository-Äquivalent.
  • Füge einen deterministischen Workload-Treiber und stabile Marker hinzu, wenn diese fehlen.
  • Speichere Befehle, Umgebungsmetadaten, Versionen von Analyse-/Tool-Programmen und offizielle Referenzlinks neben Artefakten.
  • Analysiere zuerst inklusive Kosten, dann exklusive Kosten, Callees, Wartezeiten, Warteschlangen, Synchronisation und Eigentümerschaft.
  • Ändere Code erst, nachdem die dominante Ursache gestützt ist.
  • Füge einen Benchmark, ein Regressionsbudget, einen Telemetrie-Marker, ein Trace-Rezept oder eine Lebensdauer-Invariante hinzu, die ein Wiederauftreten verhindert.
  • Halte große Trace-, Capture-, Dump- und Benchmark-Artefakte außerhalb von Git, es sei denn, die Repository-Richtlinie speichert sie explizit.
  • Validiere Fehler-, Abbruch-, Überlast-, Bereinigungs-, Geräteverlust- und Herunterfahrpfade – nicht nur den Happy Path.

Ungültige Schlussfolgerungen zur Ablehnung

  • „CPU ist hoch, also ist Methode X langsam“ ohne Stacks.
  • „RSS ist gewachsen, also leckt der verwaltete Heap.“
  • „Der GC-Heap ist stabil, also gibt es kein Leck.“
  • „Die durchschnittliche Latenz/Framezeit liegt unter dem Budget, also sind die Ausreißer gesund.“
  • „Die GPU-Auslastung ist hoch, also ist Shader X der Engpass.“
  • „Der Render-Thread ist beschäftigt, also ist die GPU beschäftigt.“
  • „Ein Frame-Capture repräsentiert das stationäre Verhalten.“
  • „Weniger Draw-Aufrufe bedeuten immer schnelleres Rendering.“
  • „Mehr ThreadPool-Threads beheben Mangel.“
  • „Async-Code kann nicht blockieren.“
  • „NativeAOT ist automatisch schneller.“
  • „Eine Mikrobenchmark-Verbesserung beweist eine Anwendungsverbesserung.“
  • „Ein statistisch nachweisbares Delta ist automatisch produktbedeutsam.“
  • „Ein Benchmark-Durchlauf beweist das Ergebnis.“

Dokumentations-Fußnoten

Footnotes

  1. references/command-reference.md, das auf die aktuelle offizielle Dokumentation für die .NET-Diagnosetools, BenchmarkDotNet, Xcode Instruments, Windows Performance Toolkit, Linux perf/BCC, PresentMon, RenderDoc und GPU-Profiler von Anbietern verweist. ↩

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community