Generators في Python للمتوسط: عالج ملف 50GB بـ 12MB رام بدون ما السيرفر يقع

الكود الغلط - بيموّت السيرفر

النتيجة على سيرفر Hetzner CCX23 بـ 32GB RAM: MemoryError بعد 2 دقيقة و 24 ثانية. الـ process اتقتل بـ OOM Killer عند الـ 30 جيجا. اللوج بيقول "Killed".

الكود الصح - Generator

النتيجة على نفس السيرفر بالظبط: الـ memory peak = 12 ميجا، وقت التنفيذ = 3 دقايق و 48 ثانية. توفير 99.97% من الذاكرة بـ yield واحدة بدل append+return. الفرق في الوقت بسيط (24 ثانية زيادة) لأن الـ I/O هو الـ bottleneck الحقيقي مش الـ CPU.

Generator Expressions: الـ shortcut اللي مش الكل بيعرفها

زي ما عندك List Comprehension بـ [x*2 for x in lst]، عندك Generator Expression بنفس الشكل بس بقوسين () بدل []:

القاعدة العملية: لو هتمرّ على البيانات مرة واحدة بس، استخدم Generator Expression. لو محتاج تعدي عليهم مرتين، استخدم List (لأن Generator بيـ exhaust ومش هترجع تاني).

Pipeline من 3 Generators متربطين

الجمال الحقيقي إنك تربط Generators في pipeline. كل واحد بيستهلك من اللي قبله بدون ما الذاكرة تتراكم في أي طبقة:

على ملف 18 جيجا فيه 84 مليون سطر JSON: الذاكرة المستخدمة عمرها ما عدّت 14 ميجا، رغم إن الـ pipeline بيمر بـ 3 طبقات تحويل.

الـ Trade-offs: كل اختيار له ثمنه

• المرور مرة واحدة فقط: Generator بيتـ exhaust بعد الـ loop الأول. لو محتاج تمر مرتين، يا إما تحفظ النتيجة في list (وتفقد ميزة الذاكرة)، يا إما تنشئ Generator جديد، يا إما تستخدم itertools.tee (اللي بيـ buffer العناصر داخلياً).
• صعوبة الـ debugging: مينفعش تطبع gen بـ print(gen) وتشوف العناصر. لازم تحوّله مؤقتاً بـ list(gen) أو تستخدم itertools.islice لمعاينة أول N عنصر بدون استهلاك الباقي.
• الـ random access مش موجود: gen[1000] هيرمي TypeError. لو محتاج تقفز لعنصر معين بترتيبه، Generator مش الحل أصلاً.
• الـ overhead في الـ calls: كل yield فيه context switch صغير. لو الـ function بسيطة جداً والـ collection صغيرة (أقل من 1000 عنصر)، List comprehension بيكون أسرع بـ 8-12% حسب قياسات Python 3.13.

متى لا تستخدم Generators

Generators مش الحل الصح في 4 حالات محددة:

1. البيانات صغيرة (أقل من 10MB): الفرق في الذاكرة مش هيتلاحظ، وعقبة الـ debugging أكبر من المكسب. خلّيك على List.
2. محتاج تمر على نفس البيانات أكتر من مرة: هتعمل الشغل مرتين بدل ما تخزّنه. الـ trade-off ضدك.
3. الـ API بتاعتك بتطلب list صريحة: مكتبات زي pandas.DataFrame() أو numpy.array() هتـ consume الـ generator كله في الذاكرة فوراً، فمفيش فايدة من الـ laziness أصلاً. استخدم pd.read_csv مع chunksize بدلاً منه.
4. محتاج تعرف الـ length مقدماً: len(gen) مش هيشتغل ويرمي TypeError. لو محتاج progress bar مع الحجم الكلي (زي tqdm)، استخدم list أو احسب الحجم بشكل منفصل قبل البدء.

الافتراضات اللي بنيت عليها الأرقام

كل القياسات أعلاه على Python 3.13.0، Linux kernel 6.6، Hetzner CCX23 (16 vCPU، 32GB RAM، NVMe SSD). على hardware أبطأ في الـ I/O (HDD مثلاً) الفرق في الوقت ممكن يكون أكبر. الفرق في الذاكرة بيفضل ثابت تقريباً لأنه مرتبط بحجم الـ Python objects مش بالـ disk.

المصادر والمراجع

• PEP 255 - Simple Generators (Magnus Lie Hetland, 2001): القاعدة الأصلية لـ yield في Python، رابط: peps.python.org/pep-0255
• PEP 380 - Syntax for Delegating to a Subgenerator (Greg Ewing, 2009): إضافة yield from لربط Generators، رابط: peps.python.org/pep-0380
• توثيق Python 3.13 الرسمي - Yield Expressions: docs.python.org/3/reference/expressions.html#yield-expressions
• توثيق itertools الرسمي - أدوات لازمة مع Generators (tee, islice, chain): docs.python.org/3/library/itertools.html
• القياسات بـ tracemalloc.get_traced_memory() من المكتبة القياسية، ومراقبة الذاكرة بـ /usr/bin/time -v لـ Maximum resident set size.

الخطوة التالية

افتح أكبر سكربت Python في مشروعك دلوقتي وابحث عن append() داخل loop بيقرا من ملف أو DB أو API. غيّر الـ function لتستخدم yield بدل append+return، وقيس الذاكرة قبل وبعد بـ tracemalloc.get_traced_memory(). لو الفرق أكتر من 50%، انت لقيت bottleneck حقيقي ووفّرت ساعات debugging مستقبلية. لو الفرق أقل من 10%، الـ generator مش الحل عندك — البيانات صغيرة والـ List أنسب.