Performance Analysis

Analyze code for performance issues across Ecto, LiveView, and OTP layers. Prioritize findings by impact and effort.

Usage

/phx:perf                           # Analyze full project
/phx:perf lib/my_app/accounts.ex    # Analyze specific module
/phx:perf --focus ecto              # Ecto queries only
/phx:perf --focus liveview          # LiveView memory only
/phx:perf --focus otp               # OTP bottlenecks only

Arguments

$ARGUMENTS = Optional module/context path and --focus flag.

Iron Laws

1. MEASURE BEFORE OPTIMIZING — Never optimize without evidence of a problem
2. DATABASE FIRST — 90% of Elixir performance issues are query-related
3. ONE CHANGE AT A TIME — Isolate optimizations to measure impact
4. NEVER benchmark in dev mode — Always use MIX_ENV=prod for performance measurements; dev mode includes code reloading, debug logging, and unoptimized compilation that invalidate results

Workflow

Step 1: Identify Scope

Check specific file if provided. Otherwise scan full project:

# Find hot paths: contexts, LiveViews, workers
find lib/ -name "*.ex" | head -50

Step 2: Run Analysis Tracks

Spawn analysis agents in parallel based on focus:

Ecto Track (default or --focus ecto):

Spawn elixir-phoenix:elixir-reviewer with prompt: "Analyze for N+1 queries, missing preloads, unindexed queries, and inefficient patterns. Check: Repo.all in loops, Enum.map with Repo calls, missing preload, queries without indexes on WHERE/JOIN columns."

LiveView Track (default or --focus liveview):

Spawn elixir-phoenix:elixir-reviewer with prompt: "Analyze LiveViews for memory issues: large assigns, missing streams for lists, assigns that grow unbounded, heavy handle_info processing, missing assign_async for slow ops."

OTP Track (only with --focus otp):

Spawn elixir-phoenix:otp-advisor with prompt: "Analyze for OTP bottlenecks: GenServer mailbox growth, synchronous calls in hot paths, missing Task.async for parallel work, ETS opportunities for read-heavy state."

Step 3: Prioritize Findings

Score each finding on a 2x2 matrix:

High impact = affects response time, memory per user, or query count. Low effort = single file change, no migration needed.

Step 4: Present Top 5

Present findings sorted by priority:

## Performance Analysis: {scope}

### 1. {Finding} — DO FIRST
**Impact**: {what improves}
**Location**: {file}:{line}
**Current**: {problematic pattern}
**Fix**: {optimized pattern}
**Estimated gain**: {e.g., "eliminates N+1, reduces queries from O(n) to O(1)"}

### 2. {Finding} — PLAN
...

Step 5: Offer Next Steps

Always end with actionable next steps — findings without follow-up get lost. Present options based on severity:

How would you like to proceed?

- `/phx:plan` — Create a plan from these findings (recommended for 3+ fixes)
- `/phx:quick` — Apply top priority fix directly (1-2 simple fixes)
- `/phx:investigate` — Deep-dive into a specific finding

Tidewave Integration

If Tidewave MCP is available:

• Use mcp__tidewave__project_eval to run Repo.query!("EXPLAIN ANALYZE ...") on suspicious queries
• Use mcp__tidewave__project_eval to check Process.info(pid, :message_queue_len) for GenServer bottlenecks
• Use mcp__tidewave__execute_sql_query to check missing indexes

References

• ${CLAUDE_SKILL_DIR}/references/benchmarking.md — Benchee patterns, profiling, flame graphs