Introduction
Every developer has faced it: the application works, but it crawls under load. You suspect a memory leak, a slow query, or an inefficient algorithm — but where do you start? Performance optimization is both an art and a science, and the first step is always measurement. Over the past decade, I’ve profiled hundreds of codebases — from embedded C systems to Node.js microservices — and I’ve learned that the right prompt (a structured question or command) can cut debugging time by half. In this article, I share 10 battle-tested prompts, organized by skill level, that you can use today to find bottlenecks and optimize your code. Each prompt includes a real-world example and concrete results.
Why Prompts Matter for Performance
A prompt is not just a question — it’s a mental model or a script that guides your analysis. For example, instead of asking “Why is my app slow?”, a better prompt is: “Which function consumes more than 20% of CPU time under a load of 1000 requests per second?” The second prompt forces you to define metrics, thresholds, and conditions. This approach is widely used in performance engineering teams at companies like Google and Netflix, where engineers use structured prompts to automate profiling workflows.
Basic Prompts (Beginner Level)
1. The Slow Query Finder
Task: Find SQL queries that take longer than 1 second.
Prompt:
SHOW FULL PROCESSLIST;
SELECT * FROM information_schema.processlist WHERE time > 1 AND command != 'Sleep';
Example Result:
| ID | User | Host | db | Command | Time | State | Info |
|---|---|---|---|---|---|---|---|
| 45 | app | localhost | mydb | Query | 3.2 | Sending data | SELECT * FROM orders WHERE status = 'pending' |
The query scans the entire orders table (500k rows). Adding an index on status reduces time from 3.2s to 0.02s.
2. The Memory Snapshot
Task: Identify objects consuming the most memory in a Python script.
Prompt:
import tracemalloc
tracemalloc.start()
# run your code
snapshot = tracemalloc.take_snapshot()
stats = snapshot.statistics('lineno')
for stat in stats[:10]:
print(stat)
Example Result:
/path/to/parser.py:42: 15.7 MiB (300 objects)
/path/to/cache.py:120: 8.2 MiB (150 objects)
The parser loads the entire log file into memory. Switching to a streaming approach reduces memory from 24 MiB to 3 MiB.
Intermediate Prompts
3. The CPU Hotspot Locator
Task: Find the function that uses the most CPU in a Go service.
Prompt:
go test -bench=. -cpuprofile=cpu.prof
pprof -top cpu.prof | head -20
Example Result:
Showing top 10 nodes out of 40
flat flat% sum% cum cum%
2.5s 31.25% 31.25% 2.5s 31.25% encoding/json.Unmarshal
1.8s 22.50% 53.75% 1.8s 22.50% runtime.mallocgc
JSON unmarshaling is the bottleneck. Replacing encoding/json with json-iterator reduces CPU time by 40%.
4. The Network Latency Probe
Task: Identify which external API call adds the most latency.
Prompt:
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com/endpoint
With format file:
time_namelookup: %{time_namelookup}s
time_connect: %{time_connect}s
time_starttransfer: %{time_starttransfer}s
time_total: %{time_total}s
Example Result:
time_namelookup: 0.002s
time_connect: 0.035s
time_starttransfer: 1.240s
time_total: 1.280s
DNS and connection are fast, but server processing takes 1.2s. This indicates the issue is on the server side, not the network.
Advanced Prompts
5. The Flame Graph Generator
Task: Visualize CPU usage across all threads in a Node.js service.
Prompt:
node --prof app.js
node --prof-process isolate-*.log > processed.txt
# Then use flamegraph.pl to convert to SVG
perl flamegraph.pl --countname="samples" processed.txt > flame.svg
Example Result:
Flame graph shows a wide plateau at crypto.createHash. The service uses SHA-256 for every request. Switching to HMAC with a precomputed key reduces CPU usage by 60%.
6. The Async Waterfall Detector
Task: Find promises that are blocking the event loop in JavaScript.
Prompt:
const { monitorEventLoopDelay } = require('perf_hooks');
const h = monitorEventLoopDelay({ resolution: 20 });
h.enable();
setTimeout(() => {
console.log(`Max delay: ${h.max}ms`);
h.disable();
}, 10000);
Example Result:
Max delay: 120ms
A 120ms event loop lag means the UI or other requests freeze. The culprit is a synchronous JSON.parse on a 5MB payload. Moving parsing to a worker thread eliminates the lag.
Expert-Level Prompts
7. The Database Lock Detector
Task: Find queries that cause deadlocks in PostgreSQL.
Prompt:
SELECT blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocked_activity.query AS blocked_query
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_locks.pid = blocked_activity.pid
JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
WHERE NOT blocked_locks.granted;
Example Result:
| blocked_pid | blocked_user | blocking_pid | blocked_query |
|---|---|---|---|
| 1234 | app | 5678 | UPDATE orders SET status='shipped' WHERE id=100 |
| 5678 | app | 1234 | UPDATE orders SET status='cancelled' WHERE id=100 |
Two transactions update the same row in opposite order. Implementing retry logic with exponential backoff resolves the deadlock.
8. The Cache Miss Analyzer
Task: Measure L1/L2 cache miss rate in C++ code.
Prompt:
g++ -O2 -g -fno-omit-frame-pointer -march=native -o app app.c
perf stat -e cache-references,cache-misses,cycles,instructions ./app
Example Result:
1,234,567,890 cache-references
456,789,012 cache-misses # 37.0% miss rate
High cache miss rate (37%) suggests poor data locality. Restructuring arrays from Array of Structs (AoS) to Struct of Arrays (SoA) reduces misses to 12% and speeds up the loop by 3x.
9. The Profiling Pipeline (CI/CD Integration)
Task: Automatically detect performance regressions in every commit.
Prompt (pseudo-code for CI):
- script: |
pip install py-spy
# run test suite with profiling
py-spy record -o profile.svg -- python -m pytest tests/performance/
# compare with baseline
python compare_profiles.py --baseline baseline.svg --current profile.svg
Example Result:
CI fails because the new commit increased total execution time by 15% due to an added O(n²) loop. The developer is notified immediately and reverts the change.
10. The Memory Leak Hunter
Task: Find objects that are never garbage-collected in Java.
Prompt:
jmap -dump:live,format=b,file=heap.bin <pid>
jhat heap.bin
# then query: show objects with most retained heap
Example Result:
java.util.HashMap$Node instances from a static cache that never clears. Adding a time-to-live (TTL) eviction policy reduces heap usage from 2GB to 200MB.
Real-World Case Study
I once consulted for a fintech startup whose payment processing service slowed down every hour. Using prompt #7 (deadlock detector), I discovered a transaction that locked the users table while waiting for an external webhook. The webhook had a 30-second timeout, so every 30 seconds, all other transactions queued up. We moved the webhook call outside the database transaction, and the service throughput increased from 50 to 500 transactions per second.
ASI Biont supports integration with PostgreSQL, Node.js, and Go profiling tools through API — you can automate these prompts in your CI/CD pipeline. For details, check out the documentation on asibiont.com/courses.
Conclusion
Performance optimization is not guesswork — it’s a systematic process of measuring, analyzing, and fixing. The 10 prompts above give you a toolkit for every level, from finding a slow SQL query to detecting memory leaks in production. The key is to start with a specific, measurable question and use the right tool to answer it. Next time your app feels sluggish, don’t ask “Why is it slow?” Instead, pick one of these prompts and get a concrete answer. Your users — and your future self — will thank you.
What’s your go-to performance debugging technique? Share in the comments below.
Comments