Performance Basics

Expected level: Awareness

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

  1. Define “slow”. Pick a target, such as “the page loads in under two seconds”.
  2. Measure a baseline with realistic data.
  3. Find the bottleneck with a profiler or by timing sections of code.
  4. Change one thing, then measure again.
  5. 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?

Related topics

Terms

Further reading