ralphctl-performance-optimization

Performance Optimization

Adapted from addyosmani/agent-skills — "Performance Optimization" (MIT). Adapted for ralphctl's harness contract.

Performance work without measurement is guessing, and guessing adds complexity that costs more than the speed it buys. Measure, find the real bottleneck, fix that one thing, measure again — and keep only what the numbers justify.

When not to use: there is no evidence of a problem. Optimising on a hunch is how neutral complexity lands.

When this applies

• Execute — when the task carries a performance target or a slowness report, or the change touches a hot path. The generator measures with the project's tooling; when reviewing, a performance claim with no before-and-after numbers behind it is a finding, and so is an "optimisation" that changed behaviour.

The workflow

MEASURE → IDENTIFY → FIX ONE THING → RE-MEASURE (keep or undo) → GUARD

1. Measure

Use what the repository already has — a benchmark target, a profiler, a timing harness, a query-plan command, a load script — found in its manifest, scripts, or CI configuration. Fix the budget before you start: the same command, the same input, the same conditions (warm or cold cache, sample count). Record the baseline numbers.

2. Identify

Let the symptom pick what to measure first:

• Startup or first load is slow — payload or bundle size, blocking work at start, slow first response.
• Interaction feels sluggish — long synchronous work on the main thread or event loop, redundant re-rendering or recomputation.
• One operation is slow — profile it; read the query plan of each query it runs.
• Everything slows at once — connection or thread pool exhaustion, memory pressure, CPU saturation.
• Slowness is intermittent — lock contention, garbage-collection pauses, a slow external dependency.
• Memory keeps growing — leaked references, unbounded caches or lists, retained payloads.