Benchmark, analyze, and optimize a function's execution time. Produces a before/after performance table with real numbers. Never presents a change without proving it is faster.
Scanned 5/27/2026
Install via CLI
openskills install v0idOS/performance-deity---
description: Benchmark, analyze, and optimize a function's execution time. Produces a before/after performance table with real numbers. Never presents a change without proving it is faster.
---
Execute all four phases in order. Do not skip any phase.
## Phase 1 — Establish Baseline
1. Identify the exact code to optimize.
2. Run a micro-benchmark:
- Write a temporary micro-benchmark script in the user's workspace.
- The script MUST contain a warm-up phase (discard ≥10 iterations).
- The script MUST run ≥100 iterations and output the Average and P95 execution time.
- Run the script using the terminal.
- Delete the temporary script after recording the results.
- *Note: If the script fails due to missing imports or dependencies, skip it and use the bash `time` command as a fallback.*
3. Record P95 and Average. Do not proceed until the benchmark runs without error.
4. Report baseline numbers before writing any new code.
## Phase 2 — Algorithmic Analysis
1. State the current Time Complexity (Big-O) explicitly.
2. State the current Space Complexity and identify the primary allocation sites.
3. Name the bottleneck precisely:
- "Nested loops causing O(n²) scaling"
- "Repeated string concatenation causing N heap allocations per call"
- "Full table scan caused by missing index on `user_id`"
## Phase 3 — Refactoring
1. Rewrite using a more efficient algorithm or data structure (apply in priority order):
- Replace Array/List lookups with Hash Sets/Dictionaries: O(N) → O(1)
- Vectorization or batching instead of per-item iteration
- Caching/memoization of expensive pure computations
- Zero-allocation patterns and buffer reuse to reduce GC pressure
- Bitwise operations where mathematically equivalent
2. Run the benchmark on the new code.
3. If the new code is not measurably faster: discard it, select a different approach, repeat.
## Phase 4 — Report
Present a Performance Report table:
| Metric | Baseline | Optimized | Δ |
|---|---|---|---|
| Average | Xms | Yms | -Z% |
| P95 | Xms | Yms | -Z% |
Follow with a one-paragraph explanation grounded in CPU/memory theory.
No comments yet. Be the first to comment!
Ultra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. Use when user says "write a commit", "commit message", "generate commit", "/commit", or invokes /caveman-commit. Auto-triggers when staging changes.
Ultra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", "/review", or invokes /caveman-review. Auto-triggers when reviewing pull requests.
Remove unused code from this project with ultrawork mode, LSP-verified safety, atomic commits. Triggers: remove dead code, dead code, cleanup, remove unused.
Verification loop for Django projects: migrations, linting, tests with coverage, security scans, and deployment readiness checks before release or PR.
一个全面的 Claude Code 会话验证系统。