performance-review

A specialisation of the parent engine.

Sub-case: performance review

A specialisation of the parent engine. The anchor changes; the refutation discipline and the report contract do not.

Anchor: workload → resource demand → growth or contention → material consequence.

The agreement being tested is between what the code assumes about its workload and what the workload will actually be. Code written against seed data agrees with a world that will not exist in production. That is the same shape as any other broken agreement: two participants, each reasonable alone.

The universal core

Language- and stack-agnostic. Apply before any technology-specific checklist.

• Repeated work — scans, parsing, serialisation, allocation, initialisation or I/O performed

again where a single pass, a hoist or a reuse would do.

• Growth relationships — how does resource use scale with input size, with concurrency, and with

elapsed time? Superlinear growth in any of the three is the finding; the constant factor is not.

• Retention — queues, buffers, caches and collections that grow without a bound, an eviction

policy or backpressure. Unbounded retention is a failure with a delay on it.

• Copying and conversion — data copied or converted between representations on a hot path,

especially at a boundary where both sides could have agreed on one representation.

• Serialisation and contention — lock duration and scope, single-threaded chokepoints,

head-of-line blocking, and work held inside a critical section that did not need to be.

• Amplification — retries, polling, fan-out and cache misses that multiply one logical request

into many real ones. Check the multiplier under failure, not under success.

Technology specialisations

Apply only where the underlying technology exists — do not report the absence of a database concept in a program that has no database. For data-backed applications (over-fetching, SELECT *, missing pagination, index definitions, caching layers), /performance-audit-static holds the detailed checklist; use it rather than restating it here.

What makes a performance finding

All three, or it is not a finding:

1. A reachable workload — the input size, rate or concurrency is one the system will actually

meet, established from the code and its context rather than assumed.

1. A resource cost or growth relationship — what is consumed, and how it scales.
2. A material consequence — latency a user feels, a cost that is paid, a limit that is hit, or a

failure that results.

Refutation

Refute against real bounds, amortisation, reuse, actual call frequency, and deliberate trade-offs. A nested loop over a collection with a hard bound of four is not a finding. A missing cache in code called once at startup is not a finding.

Distinguish measurement from static deduction, and label which you did. Never invent a timing. Never report absent caching, a nested loop, or a missing index as a finding on its own — without a workload, those are observations, not defects.