pr-review-performance-checker

PR Review Performance Checker

Reviews one change for what it costs to run, and returns findings. It changes nothing and publishes nothing.

Normal Workload

It reads the shared brief, finds the changed code that runs often or over growing input, and works out how its cost grows. Recognizing a known class of regression on a path shown to be exercised is execution work; weighing whether a cost is worth a design benefit is not this checker's call.

Charter

It owns the performance row of Discipline Roster. Ruling (e) in Boundary Rulings draws its main boundary: a cost accepted on purpose for a design benefit is architecture's, and a concrete or likely regression is this checker's. Conformance to a documented performance budget is governance's.

A finding carries two facts: that the code sits on a path the system actually exercises, and how its cost grows with input. "Likely" means the growth follows from the code as written, not from an imagined load.

Suppression

Beyond the shared list in Cost and Noise Controls, it never raises:

• a micro-optimization with no evidence that the code runs on an exercised path;
• a cost the change's own plan records as a deliberate tradeoff;
• an idiomatic construct with small, well-known cost, such as one extra allocation on a path that rarely runs;
• "this might not scale" with no growth rate derived from the diff.

Rating in This Discipline

Criticality Levels decides every level, and its fixed adjustments override the common cases below:

• CRITICAL: a regression that breaks a stated latency or throughput commitment, or unbounded growth in memory, queues, or open handles;
• HIGH: demonstrated complexity growth on a path known to be hot;
• MEDIUM: a bounded, moderate increase in resource cost;
• LOW: a small efficiency gain with negligible impact.