نوشتن و خواندن در حافظه بسیار کند است و تخصیص آن توسط سیستم عامل و بازپس گیریش از آن هم کندتر است. در زبان های managed مثل جاوا و سی شارپ تخصیص حافظه به برنامه سریعتر است زیرا این کار از حافظه ای که خود framework/runtime برنامه از سیستم عامل گرفته صورت می گیرد. در عوض حافظه تخصیص داده شده باری است بر دوش Garbage Collector. به همین دلیل در تمام برنامه ها و به خصوص در یونیتی که GC چندان خوبی ندارند و از ورژن های قدیمی Mono استفاده می کند، برنامه نویسان سعی می کنند فشار روی GC را (برای جلوگیری از توقف برنامه برای garbage collection) کم کنند.
یکی از راه های کم کردن فشار بر روی سیستم های مربوط به حافظه allocate نکردن حافظه است که در واقع بهترین راه است. چون همیشه این کار ممکن نیست برنامه نویسان سعی می کنند از تکنیکی به نام Pooling استفاده کنند. در این روش تعدادی object از نوع مورد نظر allocate می کنند و هنگام نیاز از آن ها استفاده می کنند. به جز کم کردن میزان allocation ها و قرار دادن آن ها در زمانی مشخص این تکنیک برای object هایی که ساختشان بسیار هزینه بر است مثل database connection ها و ... نیز استفاده می شود. به طور کلی در محیط های managed تکنیک object pooling برای این دو کاربرد یعنی جلوگیری از allocation/deallocation های بی رویه و زیاد و نساختن مجدد object های هزینه بر استفاده می شود. معمولا توصیه می شود که فقط در صورتی این کار را انجام دهید که profiler به شما نشان می دهد که زمان برنامه برای allocation این object ها طلف می شود. این توصیه بیشتر راجع به .NET صدق می کند و هنگام نوشتن بازی mobile در Unity شما طقریبا همیشه نیاز دارید برای اجرای بازی روی گوشی های قدیمیتر با سرعت بالا object هایی که به تعداد زیاد از آن ها استفاده می کنید را pool کنید. وقتی می گویم طقریبا همیشه دارم حرف خطرناکی می زنم زیرا این موضوع بسته به قدیمیترین گوشی که می خواهید پشتیبانی کنید و نوع بازیتان متغیر است. خود بنده بازی های موبایلی را بدون هیچ گونه poolingی منتشر کرده ام ولی در ایران معمولا بازی ها گوشی های قدیمیتری را پشتیبانی می کنند و به همین دلیل در بازی هایی که خیلی خیلی casual و ساده نباشند معمولا به این تکنیک نیاز خواهید داشت.
در روش ساده ای از این تکنیک شما می توانید یک Dictionary<GameObject,List<GameObject>> pool داشته باشید که برای هر prefab به عنوان کلید، لیستی از Object های pool شده را نگه دارد. بهتر است کل pool را درون یک کلاس abstract کنید و هنگام ساخت object ها آن ها را از pool گرفته و SetActive(true) را برایشان صدا بزنید و هنگام از بین بردن یک object برای آن SetActive(false) صدا بزنید و آن را به لیست درون pool برگردانید. برای ساخت pool هایی از object هایی به جز GameObject باید خودتان آن را فعال و غیر فعال کنید. همچنین اگر برای reset شدن object ها نیاز به منطق خاصی است باید ساختاری در component هایتان برای صدا زدن این منطق قبل از ساخت آن و گرفتنش از pool پیاده سازی کنید. مثلا می توانید یک component به نام ResetableComponent داشته باشید با یک متد virtual که آن را بهنگام ساخت، برای object صدا می زنید.
در سرور ها شما معمولا object هایی که خیلی استفاده می شوند و مثلا برای serialization/deserialization داده و یا پاسخ گویی به درخواست ها کاربرد دارند را pool می کنید. به جز آن ها کانکشن های پایگاه داده و کلاینت های HTTP و ... نیز در بیشتر موارد pool می شوند. هنگام ساخت pool در کد های سرور خود باید profiler و لزوم ساخت pool را خوب بررسی کنید زیرا ممکن است که GC بسیار بهتر از شما حافظه را مدیریت کند. هم JVM و هم CLR و ماشین های مجازی خیلی زبان های دیگر بسیاری کارهای پیشرفته را برای مدیریت درست حافظه نسبت به عوامل مختلفی انجام می دهند ، برای همین زیاد برای ساخت pool عجله نکنید. همچنین این کار ممکن است باعث بروز باگ در سیستم شما شود و لزوما کارتان را راحت نمی کند.
pool ها باید چند ویژگی داشته باشند. اول آن که اگر به حد کافی object درونشان نبود بتوانند برای خود چند object اضافه بسازند و ذخیره کنند. دوم آن که باید در ابتدا با تعداد قابل پیکره بندی از object ها initialize شوند. سوم و بسیار مهم آن که پس از استفادهاز pool و تمام شدن کارش، تمام object های خود را برای پاک شدن توسط GC آماده کنند. چهارم که در سرور ها بسیار مهم است آن که هیچ poolی نباید بی نهایت بزرگ شود و شما باید در صورت نیاز نداشتن، object های اضافه ساخته شده در pool را پاک کنید و همچنین باید قابلیت reset کردن pool را هم داشته باشید. مثلا اگر pool شما دارای 64 عدد object است. برای دادن object به دیگر بخش های برنامه object کم می آورید و 32 object جدید می سازید و اندازه poolتان 96 عدد و بعد از مدتی مشاهده می کنید که مدت ها است که بیش از 80 object در pool خود دارید. بهتر است در این حالت بخشی از object های اضافه را پاک کنید و اندازه pool را دوباره به همان 64 تغییر دهید.
