Performance Basics
Performance is about how quickly and efficiently software does its work: response time, throughput and use of CPU, memory, disk and network. The central rule is to measure first and change second.
Measure first
- Define “slow”. Pick a target, such as “the page loads in under two seconds”.
- Measure a baseline with realistic data.
- Find the bottleneck with a profiler or by timing sections of code.
- Change one thing, then measure again.
- Stop when you reach the target.
Tuning code before you know it matters (“premature optimisation”) costs readability and rarely pays off. Write clear code first; see Clean Code and Naming.
# Python: simple timing
import time
start = time.perf_counter()
do_work()
print(f"{time.perf_counter() - start:.3f} s")
Typical causes of slowness
- Waiting. Most applications spend their time on network calls, disk and database queries.
- Too many round trips. Calling a database or API once per item in a loop (the “N+1” problem) instead of fetching in bulk.
- Missing indexes, or queries that read more data than needed. See Indexing Basics.
- Poor algorithms or data structures, such as scanning a list inside a loop. See Time and Space Complexity.
- Large payloads, loaded entirely into memory or sent uncompressed.
- Repeating work that could be done once.
- Blocking work on a thread that should stay responsive, such as a UI.
Common remedies
- Fetch less data, or fetch it in batches.
- Cache results that are expensive and rarely change, and decide how they expire; stale caches are a bug source.
- Move slow work to the background; see Concurrency and Parallelism.
Production needs monitoring too, since real load behaves differently from your laptop.
Try it
Write a script that compares every pair in a list of 5,000 items. Time it, run it under a profiler (in Python: python -m cProfile -s cumulative script.py), find the hot spot and improve it. Time it again.
Common mistakes
- Optimising code before measuring where the time goes.
- Calling a database or API once per item in a loop (the N+1 problem).
- Caching without deciding how entries expire, which leaves stale data.
- Testing only with small data on a laptop and expecting the same result in production.
Check yourself
- What are the five steps of measuring performance?
- What is the N+1 problem?
- Why is a stale cache a bug source?