# Perf

> Performance analysis: bundle size checks, profiling, benchmarks, and algorithmic complexity review. Identifies performance-sensitive areas and creates a structured GitHub issue.

- Skill: `rube-de/perf` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rube-de/perf`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rube-de/perf/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: rube-de (https://skillmd.com/u/rube-de)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rube-de/perf

---


# 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](../dlc/references/ISSUE-TEMPLATE.md) now** for the issue format, and **read [../dlc/references/REPORT-FORMAT.md](../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:

| Indicator | Check Type | Tools |
|-----------|-----------|-------|
| `webpack.config.*` / `vite.config.*` / `next.config.*` | Bundle analysis | `webpack-bundle-analyzer`, `vite-bundle-analyzer`, `@next/bundle-analyzer` |
| `lighthouse` in deps or CI config | Lighthouse | `lighthouse` CLI |
| `bench` / `benchmark` dirs or scripts | Benchmarks | Project-specific (e.g. `vitest bench`, `cargo bench`, `go test -bench`) |
| `docker-compose*` / `Dockerfile` | Container analysis | `dive`, `docker image inspect` |
| `tsconfig.json` / `package.json` (with build scripts) | Build time | Time the build command |

## Step 2: Run Performance Tools

### Bundle Analysis (Web Projects)

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

```bash
# 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)

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

### Benchmarks

```bash
# 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

```bash
# 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):

| Finding Type | Severity |
|-------------|----------|
| Bundle size regression > 50% | **Critical** |
| O(n^3) or worse in hot path | **Critical** |
| Lighthouse performance score < 50 | **High** |
| O(n^2) in frequently-called code | **High** |
| Bundle size > project target | **Medium** |
| Missing database indexes on queried columns | **Medium** |
| Synchronous blocking in async context | **Medium** |
| Minor optimization opportunities | **Low** |
| Benchmark results (informational) | **Info** |

## Step 4: Create GitHub Issue

**Read [../dlc/references/ISSUE-TEMPLATE.md](../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

Acquire `BRANCH` for the Scan Metadata table above — ISSUE-TEMPLATE.md's lifecycle acquires `REPO` itself. Then follow ISSUE-TEMPLATE.md's **Issue Creation Command** lifecycle exactly — substitute `{skill-name}` = `perf`, `{Type}` = `Performance`, `{type}` = `perf`, `{additional-required-sections}` = `'## Raw Output'`:

```bash
BRANCH=$(git branch --show-current)
echo "BRANCH=$BRANCH"   # ISSUE-TEMPLATE.md's Write step is a separate tool call and can't see this shell's variables
```

## Step 5: Report

```text
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."