Performance deity

Performance Deity: Hot-Path Optimization

Description

This skill enforces a rigorous, math-driven approach to code optimization. The agent is forbidden from guessing what makes code faster. It must prove it through benchmarking.

Triggers

Activate this skill whenever the user asks to:

• "optimize" a function, file, or script.
• "speed up" or "refactor for speed".
• "benchmark" or "profile" a specific workflow.
• Or explicitly runs the command /plugin performance-deity:optimize

Core Directives

When activated, you (the agent) MUST follow these exact steps sequentially. Do not skip any steps.

Phase 1: Establish Baseline

1. Identify the target code the user wants to optimize.
2. Use the included tools to run a micro-benchmark for the target language:
   • Python: Use tools/benchmark.py "<code snippet>"
   • Node/JS: Use node tools/benchmark.js "<code snippet>"
   • PowerShell: Use tools/Measure-Performance.ps1 -Command "<cmd>"
   • Bash/Shell: Use bash tools/benchmark.sh "<cmd>"
   • If the language isn't supported by these tools, write a custom micro-benchmark script that calculates Average and P95.
3. Execute the benchmark. Ensure there is a "warm up" phase. Record the P95 and Average execution time over at least 100 iterations.
4. Report the baseline to the user. Do not proceed to Phase 2 until you have verified the benchmark runs successfully.

Phase 2: Algorithmic Analysis

1. Analyze the Time Complexity (Big-O) of the current implementation.
2. Analyze the Space Complexity (Memory allocations).
3. Explicitly identify the bottleneck. State it clearly (e.g., "Nested loops causing O(n^2) scaling", "Unnecessary object creation causing GC pauses", "String concatenation in a tight loop").

Phase 3: Recursive Refactoring

1. Rewrite the code using a more efficient algorithm or data structure.
2. High-Priority Techniques:
   • Replace Arrays/Lists with Hash Sets/Dictionaries for lookups (O(N) -> O(1)).
   • Vectorization or batching instead of individual processing.
   • Caching/Memoization of expensive calculations.
   • Reducing garbage collection overhead (zero-allocation patterns, reusing buffers).
   • Bitwise operations where mathematically applicable.
3. Run the micro-benchmark on your new code.
4. CRITICAL DIRECTIVE: If the new code is NOT significantly faster than the baseline, you must discard your changes, apologize internally, and try a different approach. Do not present failed optimizations to the user.

Phase 4: Final Proof

1. Present the final, optimized code to the user.
2. Output a Performance Report table comparing the:
   • Baseline Execution Time
   • New Execution Time
   • Percentage Improvement (%)
3. Briefly explain why the new code is faster based on CPU architecture or memory layout.