When do you choose threading, multiprocessing, or asyncio?

Question

Accepted Answer

Python offers three concurrency models, and choosing correctly depends mainly on whether your work is **I/O-bound** or **CPU-bound** — a decision heavily shaped by the GIL (which prevents threads from running Python code in parallel).

## The three models

```text
threading        → multiple threads, ONE process. GIL-limited for CPU.
multiprocessing  → multiple PROCESSES, each its own interpreter/GIL → true parallelism.
asyncio          → single thread, cooperative coroutines yielding at await points.
```

## threading — for I/O-bound concurrency

```python
from concurrent.futures import ThreadPoolExecutor

# ✅ good for I/O — the GIL is RELEASED during I/O waits, so waits overlap
with ThreadPoolExecutor(max_workers=10) as ex:
    results = list(ex.map(download_url, urls))   # many downloads concurrently
```

Threads work well for I/O-bound tasks (network, files, DB) because the GIL is released while waiting — multiple waits proceed concurrently. They do **not** speed up CPU-bound work.

## multiprocessing — for CPU-bound parallelism

```python
from concurrent.futures import ProcessPoolExecutor

# ✅ good for CPU — separate processes each have their own GIL → use all cores
with ProcessPoolExecutor(max_workers=4) as ex:
    results = list(ex.map(heavy_computation, data))   # genuine parallelism
```

For CPU-heavy work (image processing, math, data crunching), separate processes bypass the single GIL and run truly in parallel on multiple cores. The cost: higher overhead (process startup) and data must be **serialized** between processes (no shared memory by default).

## asyncio — for high-concurrency I/O

```python
import asyncio
# ✅ best for MANY concurrent I/O operations (thousands) — lightest weight
await asyncio.gather(*(fetch(url) for url in urls))
```

asyncio handles huge numbers of concurrent I/O operations on one thread, more efficiently than threads (no per-thread overhead) — ideal for servers and high-concurrency network code.

## The decision guide

```text
CPU-bound (computation)              → multiprocessing
I/O-bound, moderate concurrency      → threading (simple, works with sync libraries)
I/O-bound, HIGH concurrency          → asyncio (thousands of connections, but needs
                                       async-compatible libraries)
Mixed CPU + I/O                       → combine (e.g. asyncio + a process pool for CPU)
```

## Why it matters

Choosing the right concurrency model is one of the most consequential Python performance decisions, and getting it wrong (the classic mistake: threads for CPU-bound work, which the GIL renders useless) leads to code that doesn't scale.

The guiding logic flows from the GIL: **threads/asyncio for I/O-bound** (GIL released during waits — concurrency works) and **multiprocessing for CPU-bound** (separate GILs for real parallelism), with asyncio preferred when concurrency is very high.

Understanding each model's strengths, costs (process overhead/serialization, asyncio's library requirements), and the I/O-vs-CPU decision is essential for writing concurrent Python that actually delivers performance.