Engineering Performance Review Code Review

Performance Code Review Prompt

Allocations in hot loops, N+1 queries, complexity against real input sizes — the performance review that thinks about production load.

Overview

Performance problems hide from functional review: the code works, the tests pass, and the N+1 query ships. This setup runs the performance focus — ten checks covering hot-loop allocations, queries inside loops, implied missing indexes, algorithmic complexity at realistic sizes, blocking I/O, cache invalidation, premature materialization, pagination, and resource leaks — demonstrated on a Python data-processing service, where the language mode adds Python's own traps: mutable defaults, broad excepts, GIL-blocking async.

How to use this resource

  1. State the load in the objective

    "Under production load" anchors the review — complexity findings need a size to be judged against.

  2. Prioritize the database findings

    N+1 and missing-index findings usually dominate everything else in real systems.

  3. Measure before fixing MINORs

    CRITICAL and MAJOR performance findings justify work; MINOR ones justify a profiler run first.

Why This Works

  • Load-framing makes the model evaluate complexity against realistic sizes, not toy inputs
  • Database-access checks catch the failures that benchmarks on local data miss
  • Language traps (mutable defaults, blocking async) ride along free with the focus checks

Best for

  • Services whose input sizes grow with the business
  • Batch jobs and pipelines reviewed only functionally so far
  • Hot paths where allocations and copies actually matter

Not for

  • Profiling — the review finds suspects; measurement convicts them
  • Deep SQL query optimization — that's the SQL Optimization Prompt with dialect and plan context

Use cases

  • Reviewing data-processing code before it meets production volumes
  • Catching the N+1 pattern that works fine on ten test rows
  • Flagging complexity that explodes at the tenth power of test size

FAQ

Does this performance review prompt fix the N+1 queries it finds, or just report them?

It reports only. The template states "Review only — report findings; do not rewrite the code," so checklist item 2 (N+1 patterns or database calls inside loops) surfaces the suspect with its severity tag and location. The code-review-prompt-generator outputs this review prompt; you run it in your assistant, then decide and apply fixes yourself.

Why does this prompt add Python checks like mutable default arguments on top of the performance list?

The language is set to Python, so checklist items 11-14 ride along: mutable default arguments, bare or overly broad except clauses, CPU-bound work blocking async, and f-string or %-built SQL instead of parameters. To review another language, regenerate in the code-review-prompt-generator with that language set so the traps change to match.

How does this review judge whether nested loops are actually a complexity problem?

The objective anchors it to "production load," and checklist item 4 judges algorithmic complexity against realistic input sizes rather than toy inputs. The prompt still measures nothing: notFor states "Profiling — the review finds suspects; measurement convicts them," so a flagged finding justifies running a profiler, not a code change on faith.

More resources from Code Review Prompt Generator

Resources that pair well

Related tools

Guides for this resource

Tip: Save time by exploring related resources and tools that integrate with this resource.