Komutla Performans İyileştirme

Performance work fails when it starts with hunches. The fastest way to slow yourself down is to optimize code that was never the bottleneck.

Your assistant is excellent at optimization, but only if you point it at real evidence. This lesson is about turning measurements into precise prompts.

Before asking for speed, ask for a profile. Have the assistant instrument the slow path and tell you where time actually goes.

Give it the symptom and the constraint, and let it propose where to measure instead of guessing at fixes.

The most common performance killer in a vibe-coded app is the N+1 query: a loop that fires one database call per item. It feels fine with ten rows and dies at ten thousand.

Ask the assistant to find these patterns and collapse them into a single batched query or a join.

A query that scans the whole table is slow no matter how clean the code is. The fix is usually an index on the columns you filter and sort by.

Share the slow query and let the assistant read the execution plan and recommend a targeted index, not a blind one on every column.

Some results are costly to compute and rarely change. Caching them trades a little staleness for a large speedup.

Ask for a cache with an explicit invalidation strategy, because a cache you cannot invalidate correctly becomes a bug factory.

Sending an email, resizing an image, or calling a third-party API inside a request makes the user wait for work they don't need to see finish.

Have the assistant move that work into a background job so the response returns immediately and the task runs reliably with retries.

Returning ten thousand rows in one response is slow to build, slow to transfer, and slow to render. Products page through data instead.

Ask for cursor-based pagination for large lists and streaming for large payloads so memory stays flat as data grows.

Optimization without a target never ends. Define a performance budget so you know when you're done and when you've regressed.

Express it concretely: a p95 latency, a payload size, or a query count, and ask the assistant to keep changes inside it.

Not every slow thing is worth fixing. Optimizing a path that runs once a day wastes effort and adds complexity that bites you later.

Ask the assistant to weigh impact against risk, and to leave clear code alone when the gain is negligible.

An optimization isn't real until it's measured again. The same profile that found the problem should confirm it's gone, with no new regression elsewhere.

Have the assistant re-run the benchmark and report the delta honestly, including any path that got slower.

Speed is never finished. As usage grows, new bottlenecks appear where there were none before.

The durable skill is the loop itself: measure, target the biggest cost, change, and re-measure. Keep your prompts anchored to data and the loop keeps paying off.

Test your understanding of prompting for performance.

Performance by prompt means feeding the assistant evidence, not guesses. Profile first, then target N+1 queries, missing indexes, expensive uncached work, and blocking tasks that belong in the background.

Set a budget, verify each win with the same benchmark, and treat optimization as a continuous loop driven by measurement.