आप threading, multiprocessing, या asyncio को कब चुनते हैं?

Question

Accepted Answer

Python तीन concurrency मॉडल प्रदान करता है, और सही विकल्प मुख्य रूप से इस बात पर निर्भर करता है कि आपका कार्य **I/O-bound** है या **CPU-bound** — एक निर्णय जो GIL (जो threads को Python कोड को समानांतर में चलाने से रोकता है) से बहुत प्रभावित है।

## तीन मॉडल

```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 — 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 I/O-bound कार्यों (नेटवर्क, फाइलें, DB) के लिए अच्छी तरह काम करते हैं क्योंकि GIL प्रतीक्षा के दौरान जारी होता है — कई प्रतीक्षाएं समानांतर में आगे बढ़ती हैं। वे CPU-bound कार्य को **कभी भी** तेज नहीं करते।

## multiprocessing — CPU-bound समानांतरता के लिए

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

CPU-heavy कार्य (image processing, गणित, डेटा विश्लेषण) के लिए, अलग प्रक्रियाएं एकल GIL को दरकिनार करती हैं और कई कोर पर सच में समानांतर में चलती हैं। लागत: अधिक ओवरहेड (प्रक्रिया स्टार्टअप) और डेटा को प्रक्रियाओं के बीच **serialized** होना चाहिए (डिफ़ॉल्ट रूप से साझा मेमोरी नहीं)।

## asyncio — 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 एक thread पर बहुत बड़ी संख्या में concurrent I/O ऑपरेशन को संभालता है, threads की तुलना में अधिक कुशलता से (कोई per-thread ओवरहेड नहीं) — सर्वर और high-concurrency नेटवर्क कोड के लिए आदर्श।

## निर्णय मार्गदर्शक

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

## यह महत्वपूर्ण क्यों है

सही concurrency मॉडल चुनना Python के सबसे महत्वपूर्ण प्रदर्शन निर्णयों में से एक है, और इसे गलत करना (क्लासिक गलती: CPU-bound कार्य के लिए threads, जो GIL को बेकार बनाता है) ऐसे कोड की ओर जाता है जो scale नहीं करता है।

मार्गदर्शक तर्क GIL से निकलता है: **I/O-bound के लिए threads/asyncio** (GIL प्रतीक्षा के दौरान जारी होता है — concurrency काम करती है) और **CPU-bound के लिए multiprocessing** (वास्तविक समानांतरता के लिए अलग GIL), asyncio को प्राथमिकता दी जाती है जब concurrency बहुत अधिक हो।

प्रत्येक मॉडल की शक्तियां, लागत (प्रक्रिया ओवरहेड/serialization, asyncio की library आवश्यकताएं), और I/O-vs-CPU निर्णय समझना ऐसे concurrent Python लिखने के लिए आवश्यक है जो वास्तव में प्रदर्शन प्रदान करता है।