Audit Code for Performance Bottlenecks

This prompt turns the model into a focused performance reviewer that hunts for the specific, high-cost problems that actually slow software down: bad algorithmic complexity, repeated work, and database or I/O patterns like N+1 queries. The four numbered checks and the 'prioritize by impact' instruction force a ranked, actionable answer instead of a scattershot list, and the explicit ban on premature micro-optimizations keeps it from wasting your time on irrelevant nitpicks. Reach for it when a function or endpoint feels slow and you want a second pair of eyes before you profile.

What you can expect back

Ranked by impact:

1. N+1 query pattern (high). You run one User query and one Order query per id, so 100 ids means ~200 round trips. Fix: fetch all users in one query with User.id.in_(user_ids), then load orders with a single grouped query or a JOIN. Expected: ~200 queries down to 2, often a 10-50x latency win.

2. Counting orders by loading them (medium). len(orders) pulls every Order row just to count. Use a COUNT aggregate (func.count grouped by user_id) so you transfer counts, not full rows.

3. No handling for missing users (correctness, low perf). .first() can return None and crash on user.is_active; filter is_active in the query instead.

Not worth changing now: the list comprehension vs append micro-difference is irrelevant at this scale.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Tell the model the realistic input size (e.g. 'user_ids is typically 5,000 long') so it can judge whether an O(n squared) section actually matters or is harmless.
• 02Include the data access layer or ORM in the snippet, because N+1 patterns are invisible if you paste only the business logic and hide the queries.
• 03Ask it to flag the single biggest win first and let you decide before listing the rest, which keeps you from over-optimizing a hot path that's already fast enough.
• 04Pair this with real profiler output if you have it; paste the slow span and ask the model to reconcile its static guesses with the measured numbers.
• 05Request a quick big-O summary table at the top so you can see the complexity of each function at a glance before reading the prose.

Adapt it for your case