Quand choisir threading, multiprocessing ou asyncio ?

Question

Accepted Answer

Python offre trois modèles de concurrence, et le choix correct dépend principalement de savoir si votre travail est **lié à l'I/O** ou **lié au CPU** — une décision fortement façonnée par le GIL (qui empêche les threads d'exécuter le code Python en parallèle).

## Les trois modèles

```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 — pour la concurrence liée à l'I/O

```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
```

Les threads fonctionnent bien pour les tâches liées à l'I/O (réseau, fichiers, DB) car le GIL est libéré lors de l'attente — plusieurs attentes se font concurrence. Ils **n'accélèrent pas** le travail lié au CPU.

## multiprocessing — pour le parallélisme lié au CPU

```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
```

Pour le travail intensif en CPU (traitement d'images, mathématiques, traitement de données), les processus séparés contournent le GIL unique et s'exécutent véritablement en parallèle sur plusieurs cœurs. Le coût : surcharge plus élevée (démarrage du processus) et les données doivent être **sérialisées** entre les processus (pas de mémoire partagée par défaut).

## asyncio — pour l'I/O à haute concurrence

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

asyncio gère un nombre énorme d'opérations I/O simultanées sur un seul thread, plus efficacement que les threads (pas de surcharge par thread) — idéal pour les serveurs et le code réseau à haute concurrence.

## Pourquoi c'est important

```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)
```

## Pourquoi c'est important

Choisir le bon modèle de concurrence est l'une des décisions de performance Python les plus conséquentes, et le mal choisir (l'erreur classique : les threads pour le travail lié au CPU, que le GIL rend inutile) conduit à du code qui n'évolue pas.

La logique directrice découle du GIL : **threads/asyncio pour l'I/O-bound** (GIL libéré pendant les attentes — la concurrence fonctionne) et **multiprocessing pour le CPU-bound** (GILs séparés pour un vrai parallélisme), avec asyncio préféré lorsque la concurrence est très élevée.

Comprendre les forces de chaque modèle, les coûts (surcharge du processus/sérialisation, exigences de la bibliothèque asyncio) et la décision I/O contre CPU est essentiel pour écrire du Python concurrent qui offre réellement la performance.