DLC: Performance Analysis

Run performance checks against the current project and create a GitHub issue with findings.

Before running, read ../dlc/references/ISSUE-TEMPLATE.md now for the issue format, and read ../dlc/references/REPORT-FORMAT.md now for the findings data structure.

Step 1: Identify Performance-Sensitive Areas

Scan the project to determine which performance checks are applicable:

Step 2: Run Performance Tools

Bundle Analysis (Web Projects)

Select the tool based on detected build config — run only the first matching tool:

# Detect bundler and run the matching analysis
if [ -f webpack.config.js ] || [ -f webpack.config.ts ]; then
  npx webpack --json 2>/dev/null | jq '.assets[] | {name, size}'
elif [ -f vite.config.js ] || [ -f vite.config.ts ]; then
  npx vite build --report 2>/dev/null
elif [ -f next.config.js ] || [ -f next.config.mjs ]; then
  ANALYZE=true npx next build 2>/dev/null
fi

Lighthouse (Web Projects)

# If lighthouse CLI available and there's a dev server or static build
lighthouse http://localhost:3000 --output=json --quiet 2>/dev/null

Benchmarks

# Node.js
npx vitest bench --reporter=json 2>/dev/null

# Rust
cargo bench 2>/dev/null

# Go
go test -bench=. -benchmem ./... 2>/dev/null

# Python
python -m pytest --benchmark-only 2>/dev/null

Build Time Analysis

# Time the build
time npm run build 2>&1
# or
time cargo build --release 2>&1

Claude Algorithmic Analysis (Always Run)

Even with tools, always perform manual analysis. Use the Explore agent to discover performance-sensitive areas across the codebase (hot paths, data pipelines, request handlers). Use repomix-explorer (if available) for large codebases to get a structural overview. Then use targeted Grep and Read for detailed analysis:

• Search for O(n^2) or worse patterns: nested loops over the same collection, repeated array searches
• Check for missing indexes in database queries (*.sql, ORM query files)
• Look for synchronous blocking in async contexts
• Identify N+1 query patterns in data-fetching code
• Check for unbounded data structures (lists that grow without limit)
• Review hot paths: request handlers, event loops, data pipelines

Step 3: Classify Findings

Map results to the findings format from REPORT-FORMAT.md.

Severity mapping (reinforced here for defense-in-depth):

Step 4: Create GitHub Issue

Read ../dlc/references/ISSUE-TEMPLATE.md now and format the issue body exactly as specified.

Critical format rules (reinforced here):

• Title: [DLC] Performance: {summary of top finding}
• Label: dlc-perf
• Body must contain: Scan Metadata table, Findings Summary table (severity x count), Findings Detail grouped by severity, Recommended Actions, Raw Output in collapsed details

REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
BRANCH=$(git branch --show-current)
TIMESTAMP=$(date +%s)
BODY_FILE="/tmp/dlc-issue-${TIMESTAMP}.md"

gh issue create \
  --repo "$REPO" \
  --title "[DLC] Performance: {summary}" \
  --body-file "$BODY_FILE" \
  --label "dlc-perf"

If issue creation fails, save draft to /tmp/dlc-draft-${TIMESTAMP}.md and print the path.

Step 5: Report

Performance analysis complete.
  - Checks run: {list of applicable checks}
  - Tools used: {list}
  - Findings: {critical} critical, {high} high, {medium} medium
  - Issue: #{number} ({url})

If no findings, skip issue creation and report: "No performance issues found."