www.dntips.ir
مطالب	۳۶۹۴
نویسندگان	۲۷۶
گروه‌های مطالب	۱۰۲۴
نقشه‌های راه	۱۱۹
دوره‌ها	۱۴
اشتراک‌ها	۱۷۹۱۴

عنوان:

‫افسانه کارایی بهتر AddRange نسبت به Add در EF-Core

نویسنده: وحید نصیری
تاریخ: ۱۴۰۵/۰۴/۱۳ ۰۹:۵۵
آدرس: www.dntips.ir

احتمالاً به شما هم گفته شده است که هرگز متد Add را درون یک حلقه (Loop) صدا نزنید. شاید این توصیه را یک توسعه‌دهنده ارشد در طول بازبینی کد (Code Review) به شما کرده باشد، یا آن را در یک پاسخ با صدها امتیاز مثبت در Stack Overflow دیده باشید. استدلال پشت این توصیه در ظاهر کاملاً منطقی و معتبر به نظر می‌رسد: متد Add با هر بار فراخوانی، مکانیزم DetectChanges را مجدداً اجرا می‌کند و این فرآیند اسکن با افزایش تعداد نهادهای تحت نظر (Tracked Entities)، کندتر و کندتر می‌شود. طبق این افسانه، اگر از متد AddRange استفاده کنید، هزینه این پردازش سنگین از هزاران اسکن به تنها یک اسکن کاهش می‌یابد.

اما یک نکته کلیدی در این میان نادیده گرفته شده است: این رفتار مربوط به Entity Framework 6 (EF6) بود و هرگز در معماری Entity Framework Core (EF Core) وجود نداشته است؛ نه در اولین نسخه آن در سال ۲۰۱۶ و نه در نسخه‌های مدرن امروزی. مستندات رسمی مایکروسافت این موضوع را به وضوح بیان کرده‌اند، اما این توصیه نادرست همچنان در مقالات و آموزش‌ها کپی می‌شود، زیرا در ظاهر درست به نظر می‌رسد و کمتر کسی عملکرد واقعی آن را آزمایش می‌کند.

در این مقاله، تفاوت‌های ساختاری مدیریت تغییرات در EF6 و EF Core را بررسی می‌کنیم، الگوهایی که ممکن است این هزینه سنگین را با نامی دیگر بازگردانند معرفی خواهیم کرد و در نهایت به بررسی گلوگاه‌های واقعی عملکرد در EF Core می‌پردازیم.

بررسی ریشه فنی: تفاوت EF6 و EF Core در چیست؟

برای درک بهتر موضوع، باید به مکانیزم داخلی رفتار این دو فریم‌ورک نگاهی دقیق داشته باشیم:

در EF6: هر دو متد Add و AddRange به صورت خودکار فرآیند DetectChanges را تحریک می‌کردند. فراخوانی Add به تعداد هزار بار در یک حلقه، به معنای هزار بار اسکن کامل تمام موجودیت‌های تحت نظر بود که با هر تکرار حلقه‌ بزرگ‌تر می‌شدند. این رفتار یک هزینه درجه دوم ($O(N^2)$) ایجاد می‌کرد که به شدت کارایی را کاهش می‌داد. متد AddRange در EF6 این مشکل را با افزودن دسته‌ای موجودیت‌ها و اجرای تنها یک بار DetectChanges در پایان فرآیند حل می‌کرد.
در EF Core: این فریم‌ورک یک بازنویسی کامل (Rewrite) بود و نه یک به‌روزرسانی برای EF6. در EF Core، هیچ‌کدام از متدهای Add یا AddRange مکانیزم DetectChanges را به صورت خودکار یا درون‌حلقه‌ای صدا نمی‌زنند. طبق مستندات مایکروسافت، متدهای مجموعه‌ای (Range Methods) صرفاً یک ابزار راحتی (Convenience) هستند و عملکردی کاملاً مشابه با فراخوانی‌های متوالی متدهای غیرمجموعه‌ای دارند.

EF Core مدل اسکن زودهنگام و خودکار EF6 را با یک مدل ردیابی مبتنی بر اسنپ‌شات (Snapshot-based Tracking) جایگزین کرد. صدا زدن متد Add به تعداد هزار بار در یک حلقه، صرفاً هزار موجودیت را در وضعیت Added در حافظه صف‌بندی می‌کند و تا زمانی که محرک‌های اصلی اجرا نشوند، هیچ اسکنی روی آن‌ها صورت نمی‌گیرد.

چه زمانی DetectChanges در EF Core اجرا می‌شود؟

مکانیزم DetectChanges در EF Core تنها توسط ۵ محرک مشخص اجرا می‌شود که شناخت آن‌ها برای مدیریت کارایی سیستم الزامی است:

فراخوانی SaveChanges یا SaveChangesAsync
متد ChangeTracker.Entries() و اورلودهای ژنریک آن
متد ChangeTracker.HasChanges()
متد ChangeTracker.CascadeChanges()
اولین دسترسی به نمای محلی یک DbSet از طریق ویژگی Local در طول چرخه حیات یک Context.

بنابراین، حلقه‌ای که فقط متد Add یا AddRange را صدا می‌زند و هیچ تعاملی با Change Tracker ندارد، هیچ هزینه‌ای بابت DetectChanges در طول تکرارها پرداخت نمی‌کند. اسکن واقعی تنها یک‌بار و آن هم زمان فراخوانی SaveChanges رخ می‌دهد.

تله‌ی دسترسی به Local در حلقه‌ها

گاهی توسعه‌دهندگان ناخواسته یکی از محرک‌های بالا را درون حلقه قرار می‌دهند و رفتار کند قدیمی را بازسازی می‌کنند. به کد زیر دقت کنید:

foreach (var candidate in incomingCustomers)
{
    // تله اصلی: دسترسی به ویژگی Local با هر بار تکرار حلقه
    var exists = context.Customers.Local.Any(c => c.Sku == candidate.Sku);
    if (!exists)
    {
        context.Customers.Add(candidate);
    }
}

دسترسی به Customers.Local برای بررسی وجود یک شیء در حافظه، در هر بار تکرار حلقه، EF Core را مجبور به اجرای DetectChanges می‌کند. اگر این کار را برای ۱۰,۰۰۰ رکورد انجام دهید، دقیقاً همان هزینه سنگین $O(N^2)$ قدیمی را فعال کرده‌اید. این مشکل به خاطر متد Add نیست، بلکه به دلیل فعال‌سازی ناخواسته محرک‌های Change Tracker در داخل حلقه است.

آنتی‌پترن واقعی: بررسی نتایج بنچمارک و گلوگاه واقعی

دلیل اصلی کندی فرآیندهای ثبت داده در مقیاس بالا، انتخاب بین Add یا AddRange نیست؛ بلکه فراخوانی متد SaveChanges درون حلقه است:

// آنتی‌پترن شدید: ایجاد درخواست‌های مکرر به دیتابیس
foreach (var product in incomingProducts)
{
    context.Products.Add(product);
    await context.SaveChangesAsync(); // خطای اصلی اینجاست!
}

با این کد، اگر ۱۰,۰۰۰ محصول داشته باشید، ۱۰,۰۰۰ درخواست رفت‌وبرگشت (Round-trip) به سمت دیتابیس ارسال می‌شود. تغییر Add به AddRange در این ساختار هیچ تغییری ایجاد نخواهد کرد، زیرا مشکل اصلی تعداد دفعات ارتباط با دیتابیس است.

بررسی آماری بنچمارک‌ها

بر اساس بنچمارک‌های استاندارد، الگوهای مختلف ثبت داده نتایج زیر را نشان می‌دهند:

دسته متد Add یا AddRange همراه با یک SaveChanges واحد در پایان حلقه: تفاوت عملکرد این دو در حد نویز سیستم (Measurement Noise) است و کاملاً هم‌تراز هستند.
دسته SaveChanges به ازای هر نهاد (Per-entity): بین ۶۰ تا ۱۰۰ برابر کندتر از حالت اول عمل می‌کند.

وقتی تعداد رکوردها افزایش می‌یابد (مثلاً بالای ۵۰,۰۰۰ رکورد)، سقف کارایی واقعی EF Core ارتباطی با نحوه افزودن ندارد، بلکه به محدودیت‌های زیر مربوط می‌شود:

محدودیت پارامتر در SQL Server: سقف ۲,۱۰۰ پارامتر در هر دستور، باعث می‌شود که تعداد رکوردهای قابل دسته‌بندی (Batch Size) در جداول عریض (با تعداد ستون بالا) به شدت افت کند.
فشار حافظه (Memory Pressure): هر دو متد Add و AddRange به یک میزان حافظه جهت نگهداری موجودیت‌های تحت ردیابی در فرآیند SaveChanges نیاز دارند.

چرا و چه زمانی باید از AddRange استفاده کنیم؟

با وجود اینکه AddRange مزیت عملکردی مستقیمی نسبت به Add در حلقه‌ها ندارد، اما همچنان استفاده از آن به دلایل معماری و خوانایی کد توصیه می‌شود:

خوانایی و نگهداری کد (Readability): نوشتن عبارت context.Products.AddRange(products) در یک نگاه به بررسی‌کننده کد می‌گوید که با یک عملیات دسته‌ای سروکار دارد، در حالی که یک حلقه foreach نیاز به خواندن کل بلوک کد برای درک این موضوع دارد.
حفظ یکپارچگی خطوط لوله LINQ: به شما اجازه می‌دهد خروجی یک زنجیره LINQ را به صورت مستقیم و بدون نیاز به تعریف حلقه‌های اضافی یا متغیرهای موقت ثبت کنید:

var validEntities = incomingData
    .Where(d => d.IsValid)
    .Select(d => MapToEntity(d));

context.Products.AddRange(validEntities);

جلوگیری ساختاری از تله‌ی ردیاب تغییرات: وقتی داده‌ها را ابتدا در حافظه با ساختارهای استاندارد سی‌شارپ (مانند LINQ بر روی List) فیلتر و یکتا سازی می‌کنید و سپس لیست نهایی را یک‌جا به AddRange می‌سپارید، دیگر ریسکِ برخورد با متدهایی نظیر Local یا Entries در یک حلقه متصل به دیتابیس وجود نخواهد داشت.

نتیجه‌گیری

افسانه کارایی بهتر AddRange نسبت به Add در زمان افزودن داده‌ها، یک مفهوم منسوخ‌شده متعلق به دوران EF6 است. در معماری EF Core، متد AddRange صرفاً یک متد کمکی برای افزایش خوانایی و زیبایی کد است و هیچ بهبودی در سرعت پردازش داخلی ثبت داده‌ها نسبت به متد Add (زمانی که درست استفاده شود) ایجاد نمی‌کند.

برای داشتن یک برنامه با کارایی بالا، اصول زیر را همواره مدنظر قرار دهید:

محل قرارگیری SaveChanges: همیشه مطمئن شوید که فراخوانی دستور ذخیره‌سازی خارج از حلقه‌های تکرار قرار دارد.
دوری از محرک‌های ردیاب تغییرات: از صدا زدن ویژگی Local یا متد HasChanges() در داخل حلقه‌های پردازش داده خودداری کنید.
مدیریت حجم‌های بسیار بزرگ: اگر با حجم داده‌های بسیار عظیم (مثلاً بالاتر از ۵۰,۰۰۰ رکورد) یا جداول بسیار عریض مواجه هستید، تکنیک‌هایی نظیر قطعه‌بندی داده‌ها (Chunking) جهت مدیریت مصرف حافظه Context را بررسی کنید.

مطالب مشابه

اشتراک‌هاشکستن افسانه "فیلتر زودتر، JOIN دیرتر" در بهینه‌سازی عملکرد SQL

اشتراک‌هاعملیات دسته‌ای در EF Core 10: فراتر از SaveChanges()

اشتراک‌هایادداشت‌های آموزشی .NET: مدل ذخیره‌سازی ارائه‌دهنده حافظه داخلی سفارشی (۳) - مدل نگارش و بازیابی مبتنی بر کلید

مطالبردیابی تغییرات در Entity Framework، بخش اول

مطالبکارهایی جهت بالابردن کارآیی Entity Framework #3

مطالبBulkInsert در EF CodeFirst

مطالبPHP سریعتر از ASP.NET! افسانه یا واقعیت؟

مطالبشروع به کار با EF Core 1.0 - قسمت 14 - لایه بندی و تزریق وابستگی‌ها

نظرات مطالبافسانه کارایی بهتر AddRange نسبت به Add در EF-Core

نظرات مطالبObservableCollection در Entity Framework

نظرات

علی یگانه مقدم در ۱۴۰۵/۰۴/۱۳ ۱۲:۱۰

منون بابت توضیحات
البته ما این مورد پرفورمنس رو شنیده بودیم ولی نه برای موردی که بررسی شد. در واقع آنچه ما شنیده بودیم که متد add در واقع برای هر رکورد یک کوئری درج تکی مینویسد ولی با استفاده از AddRanage کوئری به به صورت دسته ای batch یا INSERT INTO ... VALUES (...), (...), ... نوشته میشود
- وحید نصیری در ۱۴۰۵/۰۴/۱۳ ۱۴:۱۸
  این موضوع که به آن اشاره کردید (تولید یک کوئری دسته‌ای در برابر هزاران کوئری تکی)، دقیقاً یک واقعیت فنی است، اما در تفکیک دلیل وقوع آن یک جابجایی مفهومی رخ داده است. در واقع، این باور که AddRange باعث دسته‌ای شدن (Batching) کوئری‌ها می‌شود و Add تکی این کار را نمی‌کند، یک خطای تشخیصی رایج است. بیایید بررسی کنیم که در پشت صحنه EF Core واقعاً چه اتفاقی می‌افتد:
  
  مکانیزم واقعی Batching در EF Core
  تولید کوئری به صورت دسته‌ای یا همان INSERT INTO ... VALUES (...), (...), ... هیچ ارتباطی به این ندارد که شما موجودیت‌ها را با Add درون حلقه stage کرده‌اید یا با AddRange. تولید کوئری دسته‌ای، وظیفه‌ی مکانیزم درایور دیتابیس (Provider) در زمان فراخوانی SaveChanges است، نه متدهای آماده‌سازی داده.
  وقتی شما متد SaveChanges() را صدا می‌زنید، فرآیند زیر طی می‌شود:
  - هسته EF Core به سراغ Change Tracker می‌رود و تمام موجودیت‌هایی که در وضعیت Added هستند را جمع‌آوری می‌کند (فرقی ندارد تک‌تک با Add آمده باشند یا یک‌جا با AddRange).
  - لیست این موجودیت‌ها به کامپایلر کوئریِ بخش Provider (مثلاً SQL Server یا PostgreSQL) تحویل داده می‌شود.
  - درایور دیتابیس بررسی می‌کند که چه تعداد ردیف قرار است درج شود و بر اساس تنظیمات عملکردی خود (مانند ویژگی MaxBatchSize)، آن‌ها را به کوئری‌های دسته‌ای (Batched INSERTS) تبدیل می‌کند.
  مقایسه خروجی SQL در پشت صحنه
  اگر SaveChanges خارج از حلقه باشد، هر دو الگوی زیر دقیقاً یک خروجی SQL یکسان و دسته‌ای تولید می‌کنند:
  حالت اول (با استفاده از Add در حلقه):
```
foreach(var item in items)
{
    context.Products.Add(item);
}
context.SaveChanges(); 
// خروجی: INSERT INTO Products (...) VALUES (...), (...), (...)
```
  حالت دوم (با استفاده از AddRange):
```
context.Products.AddRange(items);
context.SaveChanges();
// خروجی: INSERT INTO Products (...) VALUES (...), (...), (...)
```
  پس ریشه این باور عمومی از کجا آمده است؟
  این شنیده که «متد Add کوئری تکی می‌زند و AddRange دسته‌ای»، معمولاً از دو سناریو آب می‌خورد:
  
  ۱. مقایسه اشتباه لایه‌های کد (تله همزمانی SaveChanges)
  در بسیاری از کدهای قدیمی یا آموزش‌های غیراستاندارد، وقتی توسعه‌دهنده از Add استفاده می‌کند، ناخودآگاه SaveChanges را هم درون همان حلقه قرار می‌دهد:
```
// تولید هزاران کوئری تکی و رفت‌وبرگشت به دیتابیس
foreach(var item in items) {
    context.Products.Add(item);
    context.SaveChanges(); // علت اصلی تکی شدن کوئری‌ها
}
```
  اما وقتی می‌خواهد از AddRange استفاده کند، ساختار کد او را مجبور می‌کند که ابتدا کل لیست را جمع کند و سپس یک‌بار SaveChanges را صدا بزند. در نتیجه، مقایسه بین این دو روش در اصل مقایسه Add و AddRange نیست؛ بلکه مقایسه فراخوانی مکرر SaveChanges در برابر یک‌بار فراخوانی SaveChanges است.
  
  ۲. تاریخچه نوستالژیک Entity Framework 6 (EF6)
  در نسخه قدیمی EF6 (قبل از ظهور EF Core)، مکانیزم پیش‌فرض دسته‌بندی کوئری‌ها (نیتِو Batching) وجود نداشت! در EF6 اگر شما ۱۰۰ رکورد را با متد Add یا حتی AddRange اضافه می‌کردید، EF6 به صورت پیش‌فرض ۱۰۰ دستور INSERT مجزا و تفکیک‌شده با دستور go به دیتابیس می‌فرستاد. در آن دوران برای دسته‌ای کردن واقعی کوئری‌ها، توسعه‌دهندگان ناچار بودند به سراغ کتابخانه‌های جانبی بروند. از نسخه EF Core 1.0 به بعد، مایکروسافت قابلیت Auto-Batching را به عنوان یک ویژگی کلیدی و پیش‌فرض معرفی کرد تا این ضعف تاریخی را پوشش دهد.
  
  کلام آخر
  شنیده‌ی شما درباره «نوشتن کوئری دسته‌ای» کاملاً درست و یک قابلیت حیاتی در دیتابیس است، اما این قابلیت متعلق به معماری توکار SaveChanges در EF Core است، نه متمایزکننده متد Add از AddRange. تا زمانی که SaveChanges خارج از حلقه باشد، موتور تولید کوئری EF Core به متد ورود داده‌ها اهمیتی نمی‌دهد و با هوشمندی، رکوردها را در بسته‌های بهینه‌شده (معمولاً تا ۱۰۰۰ رکورد در هر بسته برای SQL Server) دسته‌بندی کرده و ارسال می‌کند.