Optimize a Slow Function With Specific Tradeoffs

This prompt diagnoses why a function is slow at a given input size and returns ranked optimization options, each with its new complexity and an honest statement of what you'd trade away. Use it when you've found a hot path and need to choose an approach deliberately rather than reaching for the first clever trick. The forced tradeoff column is the real value — it stops the model from recommending a faster algorithm that quietly costs you memory or readability you can't afford.

What you can expect back

1. Current: O(n^2) time, O(1) extra space. The nested loop compares every pair.
2. Bottleneck: the inner loop's pairwise email comparison — ~1.25B comparisons at n=50k.
3. Approaches, ranked:
   a. Hash set of seen emails — O(n) time, O(n) space. Single pass, append on collision.
   b. Sort by email then scan adjacent — O(n log n) time, O(1)-O(n) space. No hash needed.
   c. Counter/group-by email — O(n), O(n) space, and gives you counts for free.
4. Tradeoffs: (a) costs O(n) memory but trivially readable; (b) mutates/copies order, slightly more code; (c) most memory, most flexible output.
5. Pick (a). In a request handler latency dominates and 50k emails of memory is negligible — the O(n) hash-set pass is the clear win.

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

Get sharper results

• 01State your real input distribution, not just size — 'mostly unique' versus 'heavily duplicated' can change which approach wins.
• 02Paste the actual code including the data structures it operates on, since the best optimization often depends on whether you're holding a list, generator, or DB cursor.
• 03Name your hard constraint precisely; 'latency in a request handler' and 'memory on an embedded device' lead to opposite recommendations.
• 04Ask it to flag any approach that changes observable behavior (ordering, returning duplicates vs. uniques) so you don't trade speed for a subtle bug.
• 05Request a quick benchmark snippet for the top pick so you can confirm the speedup on your real data rather than trusting Big-O alone.

Adapt it for your case