Engineering

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.

Workflow

State the load in the objective
"Under production load" anchors the review — complexity findings need a size to be judged against.
Prioritize the database findings
N+1 and missing-index findings usually dominate everything else in real systems.
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

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

REVIEW OBJECTIVE
Review the data-processing service for performance problems under production load.
Primary focus: performance — find what gets slow or expensive under real load.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a complete file — judge both the code and the file's structure: imports, ordering, and what this file owns.
Language: Python.

REVIEW CRITERIA
- Allocations and copies inside hot paths
- Database access patterns: N+1, queries in loops, missing pagination
- Algorithmic complexity against realistic input sizes
- Blocking I/O and lock contention on hot paths
- Resource lifecycle: leaks, unbounded growth, missing disposal

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Any allocations or large copies inside hot loops?
2. Any N+1 query patterns or database calls inside loops?
3. Do query patterns imply indexes that may not exist?
4. Is the algorithmic complexity acceptable for realistic input sizes (nested loops over large collections)?
5. Any blocking I/O on hot or async paths?
6. Are caching opportunities taken — and cache invalidation handled?
7. Any premature materialization (loading everything before filtering)?
8. Are large result sets paginated instead of fully loaded?
9. Any resource leaks: unclosed connections, growing collections, missing disposal?
10. Is work repeated that could be computed once?
Python-specific:
11. Any mutable default arguments?
12. Any bare or overly broad except clauses?
13. Any CPU-bound work blocking async code?
14. Any f-string or %-built SQL instead of parameters?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Prioritize findings that matter; skip pure style nits unless they hurt readability.
- If something is done notably well, say so once — briefly.

FINAL VERDICT
- End with a verdict: APPROVED, APPROVED WITH COMMENTS, or CHANGES REQUIRED.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the file here]

Related Resources

Explore more resources that work well with this one.