Optimizing Performance

Core principle: Readable code that’s “fast enough” beats complex code that’s “optimal”. Measure first.

The Golden Rule

IF optimization reduces complexity AND improves performance → ALWAYS DO IT
IF optimization increases complexity → Only if 10x faster OR fixes critical UX (>16ms UI, >100ms input)

Four-Phase Process

- [ ] Phase 1: Measure baseline (time/renders/memory/KB)
- [ ] Phase 2: Identify root cause (algorithm/I/O/payload)
- [ ] Phase 3: Evaluate cost vs benefit
- [ ] Phase 4: Implement & verify improvement

Phase 1: Measure First (REQUIRED)

Never optimize without data.

Phase 2: Identify Root Cause

Phase 3: Evaluate Cost vs Benefit

1. Reduces complexity? → Always do it
2. Increases complexity? → Only if 10x faster OR fixes critical UX
3. Otherwise → Don’t do it

Phase 4: Implement & Verify

1. Make minimal changes targeting bottleneck
2. Re-run benchmark
3. Verify tests pass

Win-Win Optimizations (Always Do)

Multiple loops → Single loop:

// ❌ Three passes
const ids = users.map(u => u.id);
const active = users.filter(u => u.active);

// ✅ One pass
const { ids, active } = users.reduce((acc, u) => {
  acc.ids.push(u.id);
  if (u.active) acc.active.push(u);
  return acc;
}, { ids: [], active: [] });

Nested loops → Hash map (O(n²) → O(n)):

// ❌ O(n²)
const matched = orders.filter(o => users.some(u => u.id === o.userId));

// ✅ O(n)
const userIds = new Set(users.map(u => u.id));
const matched = orders.filter(o => userIds.has(o.userId));

High-Value Optimizations

Red Flags

• Optimizing without benchmark data
• Micro-optimizing <16ms code
• Adding complexity for minimal gain
• Optimizing infrequently-run code