Performance Analysis

performance-analysis

Mission

Find performance bottlenecks before they affect users. This skill is proactive — it analyzes code for performance issues, not just responds to "it's slow" reports.

For writing performant code patterns (caching, eager loading, Redis), use the performance skill. For test suite performance, use test-performance.

When to use

Use this skill when:

• Auditing a codebase or flow for performance bottlenecks
• analysis-autonomous-mode routes here after detecting slow patterns
• Reviewing code that handles large datasets, loops, or external calls
• Investigating why a specific endpoint or job is slow

Do NOT use when:

• Writing new caching/optimization code → use performance
• Optimizing test suite speed → use test-performance
• Hunting for functional bugs → use bug-analyzer (proactive mode)

Procedure: Performance analysis

1. Identify hotspots

Focus on code paths with high execution frequency or large data volumes:

• API endpoints called frequently (list endpoints, dashboards)
• Queue jobs processing batches
• Scheduled commands running on large datasets
• Import/export operations
• Report generation

2. Database query analysis

3. Application-level bottlenecks

4. Queue and job analysis

• Jobs that should be batched but run individually
• Missing chunk() for large dataset processing
• Retry storms from failing jobs without backoff
• Jobs that hold database connections too long
• Missing WithoutOverlapping for idempotency-critical jobs

5. Infrastructure-level checks

• Missing Redis for session/cache (using file/database driver)
• Missing CDN for static assets
• Missing response caching for read-heavy endpoints
• Database connection pooling and limits
• Queue worker concurrency vs database connection limits

Output format

1. Emit one entry per bottleneck using the field list below; never collapse multiple bottlenecks into a single entry.
2. Severity, Effort, and Confidence are required for every entry and must use the bounded vocabulary (Low / Medium / High / Critical for severity).
3. Close with a Recommended Fix Order ranked by Impact ÷ Effort and capped at 5 items.

For each bottleneck:

• Issue: concise title
• Location: file, line, or endpoint
• Severity: Low / Medium / High / Critical
• Impact: estimated effect (e.g., "adds ~500ms per request", "causes N+1 on 100+ records")
• Evidence: code reference, query pattern, or measurement
• Fix: concrete optimization
• Effort: Low / Medium / High
• Confidence: Low / Medium / High

Integration with other skills

• analysis-autonomous-mode — routes here when performance concerns are detected
• performance — complementary: performance is about writing fast code, this is about finding slow code
• test-performance — for test suite speed specifically
• bug-analyzer — some performance issues are actually bugs (N+1, infinite loops)
• database — for deep DB optimization guidance

Gotcha

• Don't present raw numbers without context — "200ms" means nothing without knowing the baseline.
• The model tends to focus on code-level optimization when the bottleneck is a database query.
• Profiling in development differs from production — different data volumes, different query plans.

Do NOT

• Do NOT micro-optimize code that runs infrequently or on small datasets
• Do NOT recommend caching without considering invalidation
• Do NOT assume bottlenecks — measure or trace the actual code path
• Do NOT confuse code style preferences with performance issues
• Do NOT recommend infrastructure changes when code fixes would suffice