Stack vs Heap بالعربي: ليه متغير بياخد نانوثانية والثاني ميكروثانية

قياس فعلي على Go 1.22.0، MacBook M2، تشغيل واحد بـ GOMAXPROCS=1:

• stack: 4.1 ميلي ثانية لـ 10 مليون عملية ≈ 0.41 نانوثانية لكل واحدة.
• heap: 240 ميلي ثانية ≈ 24 نانوثانية لكل واحدة، بدون احتساب وقت الـ Garbage Collector اللي هيشتغل بعد كده.

الفرق ~58×. ومش بس في زمن الـ allocation. الـ Heap بيدفعك ضريبة GC pause، وبيكسر cache locality للـ CPU، وبيخلي الـ profiler بتاعك يبان فيه noise مش بالضرورة من كودك.

إيه اللي بيقرر فين المتغير يتحط

القاعدة الذهنية المبسّطة:

1. المتغير له حجم معروف وقت الـ compile وعمره ≤ عمر الدالة → Stack.
2. الحجم متغيّر (slice بيكبر، struct فيها slice)، أو هتاخد منه pointer وترجعه برّا الدالة، أو حجمه أكبر من ~8KB → Heap.

في Go تحديدًا، فيه حاجة اسمها escape analysis. الكومبيلر بيحلل الكود ويقرر بنفسه أي متغير محتاج يهرب للـ Heap. شغّل الأمر ده هتشوف القرارات بعينك:

ده مش سحر. ده static analysis بيقرّر مكان كل allocation قبل ما الكود يشتغل أصلاً. JVM HotSpot بتعمل حاجة شبيهة على runtime اسمها Scalar Replacement.

الـ trade-offs الحقيقية

الـ Stack أسرع، لكن بتدفع:

• محدود الحجم. الافتراضي على Linux 8MB لكل thread (ulimit -s). recursion عميقة أو array كبير محلي بيكسره ويجيلك stack overflow.
• عمره مربوط بالدالة. لو محتاج تشير للبيانات بعد ما الدالة ترجع، Stack مش هينفعك.
• مش مناسب لمشاركة state بين threads.

الـ Heap أمرن، لكن بتدفع:

• كل allocation أبطأ، حتى مع أحسن الـ allocators زي tcmalloc أو jemalloc.
• fragmentation مع الوقت بتقلل سرعة الـ allocations الجديدة.
• في لغات GC (Java, Go, JS, C#) بتدفع pause times. وفي C/C++ بتدفع memory leaks لو نسيت free أو delete.
• cache locality أسوء — البيانات منتشرة في الذاكرة بدل ما تكون متجاورة.

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

لو الكود بتاعك بيعمل recursion عميقة (تمشية شجرة كبيرة، parser لـ JSON متداخل، خوارزمية divide-and-conquer)، خليك على Heap من خلال iterative implementation أو explicit stack data structure. لو بتشتغل في embedded system بـ KBs قليلة من الذاكرة، الـ stack المحلية ممكن تخنقك بسرعة. ولو بتشير لنفس البيانات من أكثر من goroutine أو thread، Heap هو الاختيار الصحيح حتى لو أبطأ.

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

لو الـ object صغير (≤ 64 bytes) وعمره داخل دالة واحدة، تركه يطلع للـ Heap هدر صريح. لو في hot path بيتنفّذ ملايين المرات في الثانية (game loop، JSON parser، tight numeric kernel)، خفّض الـ heap allocations لأقصى درجة باستخدام sync.Pool في Go أو object pooling في Java. الفرضية هنا إنك بتقدر تقيس بـ profiler (pprof في Go، perf في Linux، Instruments على macOS، JFR في Java) — مش بتخمّن.

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

افتح أصغر service Go أو Java عندك في الإنتاج، شغّل go build -gcflags="-m" ./... 2>&1 | grep escape أو jcmd <PID> GC.heap_info. هتشوف بنفسك أكتر allocations كاش. فيه على الأقل 3 منهم تقدر تنقلهم للـ Stack بتعديل بسيط: return value بدل pointer، أو reuse للـ buffer عبر sync.Pool، أو استخدام array محلي بدل slice. قِس قبل وبعد بالـ benchmark، وابعت الأرقام لو شفت حاجة غريبة.

المصادر

• Go runtime — escape analysis: go doc cmd/compile ومرجع Effective Go الرسمي.
• "What Every Programmer Should Know About Memory" — Ulrich Drepper, Red Hat (2007). الورقة الأساس لفهم cache locality وتأثير الذاكرة على الأداء.
• Linux man page pthread_attr_setstacksize(3) لحدود stack size الافتراضية لكل thread.
• "Escape Analysis for Java" — Choi, Gupta, Serrano, Sreedhar, Midkiff. Sun Microsystems / OOPSLA 1999. أصل الفكرة في JVM.
• Go runtime source — src/runtime/malloc.go وsrc/runtime/stack.go لتفاصيل الـ allocator.
• قياسات الكود في المقال على Go 1.22.0، macOS arm64 (M2)، تشغيل واحد بـ GOMAXPROCS=1 لتقليل التشويش.