Performance Optimizer

Performance Optimizer

Evidence-based performance optimization. Never optimize without profiling first. Every optimization comes with a trade-off analysis.

Quick Start

Investigate a Performance Issue

1. Reproduce: Can you reliably reproduce the slowness? What are the conditions?
2. Measure: Profile to find the actual bottleneck. Don't guess.
3. Analyze: What's the root cause? Algorithm? I/O? Memory? Contention?
4. Propose: 2-3 options with trade-offs (speed vs readability, memory vs CPU, etc.)
5. Verify: After optimization, re-measure to confirm improvement.

The cardinal rule: Profile first, optimize second. Gut feelings about performance are wrong more often than right.

Profiling Toolkits

Rust

Quick benchmark setup with criterion:

// benches/my_bench.rs
use criterion::{criterion_group, criterion_main, Criterion};

fn benchmark_function(c: &mut Criterion) {
    c.bench_function("descriptive name", |b| {
        b.iter(|| {
            // code to benchmark
        })
    });
}

criterion_group!(benches, benchmark_function);
criterion_main!(benches);

TypeScript / React

Key React performance checks:

• Unnecessary re-renders (use React DevTools "Highlight updates")
• Large component trees re-rendering from state at the top
• Missing useMemo / useCallback for expensive computations or stable references
• Bundle size — are you importing entire libraries for one function?

Django / Python

Key Django performance checks:

• N+1 queries (use django-debug-toolbar or assertNumQueries in tests)
• Missing database indexes on filtered/ordered columns
• Unoptimized querysets (use .only(), .defer(), .values() when appropriate)
• Template rendering time (are you doing computation in templates?)

Complexity Analysis

Big-O Quick Reference

When to Care

• O(1) to O(n): Almost never a problem. Don't optimize.
• O(n log n): Fine for most use cases. Only optimize for very hot paths.
• O(n^2): Watch the input size. Fine for n < 1000, problematic for n > 10000.
• O(n^3) or worse: Red flag. Look for algorithmic improvements first.

Cyclomatic and Data Flow Complexity

Per the project coding standards:

• Cyclomatic complexity: Must be < 25 per function
• Data flow complexity: Must be < 25 per function

When complexity exceeds these thresholds, the refactoring-advisor skill should be used to plan decomposition.

Common Optimization Patterns

Rust-Specific

React/TypeScript-Specific

Django/Python-Specific

Trade-Off Analysis Template

When recommending an optimization, always present:

### Optimization: [Description]

**Current:** [What's happening now, with measured performance]
**Proposed:** [What to change]

| Dimension | Before | After |
|---|---|---|
| Time complexity | O(n^2) | O(n log n) |
| Space complexity | O(1) | O(n) |
| Readability | Simple nested loop | Sort + scan requires comment |
| Maintainability | Easy to modify | Requires understanding of invariant |

**Recommendation:** [Proceed / Defer / Skip]
**Justification:** [Why this trade-off is or isn't worth it in this context]

Anti-Patterns: When NOT to Optimize

• Premature optimization. If there's no measured performance problem, don't create complexity to solve one.
• Micro-optimizing cold paths. That function called once at startup? Leave it readable.
• Optimizing without benchmarks. "I think this is slow" is not evidence. Profile first.
• Sacrificing correctness for speed. Fast and wrong is worse than slow and right.
• Cargo-culting. "I read that HashMap is faster" — depends on the size, access pattern, and key type. Measure in your context.

Integration

• Data: Performance findings logged to MEMORY.md
• Tools: Can run profiling/benchmarking tools without asking (see execution policies in AGENTS.md)
• Refactoring: When optimization requires restructuring, use the refactoring-advisor skill for safe migration planning
• Trade-offs: Every optimization recommendation includes a trade-off table

Arc skill — Performance profiling and optimization