یکی از مواردی که فشاری بر روی garbage collector را بالا می‌برد، تخصیص‌های حافظه‌ی مخفی یا Hidden allocations هستند که سبب تخصیص‌های حافظه‌ی کوچک و عموما پر تعدادی بر روی heap می‌شوند. برای نمونه به مثال ذیل دقت کنید و سعی کنید تعداد تخصیص‌های حافظه‌ی آن را حدس بزنید:
public static void PrintSum(int a, int b)
{
Console.WriteLine("Sum of a {0} b {1} is {2}", a, b, a + b);
}
در این مثال ... سه تخصیص حافظه‌ی کوچک رخ می‌دهد. از این جهت که متد Console.WriteLine ایی که در اینجا استفاده می‌شود، در نهایت به یک چنین کدی کامپایل خواهد شد:
Console::WriteLine(string, object, object, object)
در این مثال بر روی تمام پارامترهای int دریافتی، عملیات boxing (تبدیل یا cast) به object صورت می‌گیرد و عملیات boxing، یک نوع allocation است که نتیجه‌ی آن بر روی heap ذخیره می‌گردد.
روشی برای نمایان ساختن تخصیص‌های حافظه‌ی نهان در ویژوال استودیو
اگر از ReSharper استفاده می‌کنید، افزونه‌ی «
Heap Allocations Viewer» آن و یا اگر از VS 2015 و Roslyn استفاده کنید، افزونه‌ی «
Roslyn Clr Heap Allocation Analyzer» آن، سبب نمایان شدن allocationهای مخفی می‌شوند. برای مثال قطعه کد فوق یک چنین نمایشی را پیدا می‌کند:
در اینجا در ذیل هر سه موردی که عملیات boxing allocation رخ داده، یک خط قرمز کشیده است. یکی از روش‌هایی که می‌تواند boxing allocation فوق را حذف کند، بکار گیری متد ToString بر روی مقادیر int است:
همانطور که مشاهده می‌کنید، اینبار دیگر خبری از خطوط قرمز، ذیل پارامترهای متد Console.WriteLine نیست. باید دقت داشت که ToString نیز سبب تخصیص حافظه می‌شود، اما اینبار دیگر int32 آن بر روی heap ذخیره نمی‌گردد. به عبارتی هر دو حالت سبب تخصیص حافظه‌ی یک رشته‌ی جدید می‌شوند؛ اما در حالت اول علاوه بر این شیء جدید، شیء int32 نیز بر روی heap ذخیره می‌گردد.
تشخیص تخصیص اشیاء مخفی با افزونه‌های Heap Allocations Viewer
نمونه‌ی دیگر پر کاربرد این نوع بهینه سازی‌ها را در مثال ذیل می‌توان مشاهده کرد:
public static void PrintA(int a)
{
Console.WriteLine("a is " + a);
}
این مثال، یک چنین نمایش بصری دارد:
اینبار یک خط زرد رنگ ظاهر شده به همراه یک خط قرمز رنگ. خط قرمز رنگ را پیشتر بررسی کردیم و علت وجودی آن Boxing allocation ایی است که رخ می‌دهد. خط زرد رنگ در ذیل + ظاهر شده‌است و عنوان می‌کند که عملیات جمع زدن رشته‌ها، سبب تخصیص حافظه‌ی یک شیء جدید می‌شود. رشته‌ها در دات نت immutable هستند. به همین جهت هر تغییری در آن‌ها، سبب تخصیص یک شیء جدید می‌شود. بنابراین در همین مثال ساده، دو تخصیص حافظه‌ی مخفی وجود دارند. مورد جمع زدن را با بکارگیری string.Format و مشکل boxing را با ToString می‌توان برطرف کرد:
public static void PrintA(int a)
{
Console.WriteLine("a is {0}", a.ToString());
} 
منابع دیگری که سبب تخصیص‌های حافظه‌ی مخفی می‌شوند
تا اینجا دو مورد از منابع متداول تخصیص‌های حافظه‌ی مخفی را بررسی کردیم. اما این لیست شامل موارد ذیل نیز می‌شود:
1) فراخوانی متدهایی با پارامترهایی از نوع param همیشه سبب تخصیص حافظه‌‌ای جهت تشکیل یک آرایه‌ی در برگیرنده‌ی پارامترهای ارسالی می‌شود.
2) متدهایی که پارامتر از نوع IEnumerable دارند:
public static int Sum(IEnumerable<int> list)
{
var sum = 0;
foreach (var number in list)
{
sum += number;
}
return sum;
}
در این مثال هربار که متد Sum فراخوانی شود، یکبار دیگر IEnumerable آن تخصیص خواهد یافت که در تصویر ذیل با enumerator allocation مشخص شده‌است:
برای حل این مشکل فقط کافی است IEnumerable را با List تعویض کنید.
3) کار با LINQ نیز سبب تخصیص‌های حافظه‌ی قابل توجهی است. برای مثال در کد پایه‌ی Roslyn، برای رسیدن به حداکثر کارآیی، بسیاری از الگوریتم‌ها را با روش‌های غیر LINQ پیاده سازی کرده‌اند. البته برای تیمی مانند Roslyn رسیدن به یک چنین کارآیی جهت رقابت با سایر محصولات مشابه ضروری بوده‌است و گرنه در بسیاری از کارهای متداول، استفاده از LINQ به خوانایی هر چه بیشتر کدها کمک شایانی می‌کند.
برای مطالعه‌ی بیشتر Roslyn code base – performance lessons - part 2 Unusual Ways of Boosting Up App Performance. Boxing and Collections On performance in .NET
