تستعرض Microsoft في تدوينة منشورة على .NET Blog بتاريخ 15 سبتمبر 2026 مئات التحسينات التي وصلت إلى .NET 11، وتقدمها بوصفها حصيلة تراكمية لعمل طال مترجم الزمن الفعلي JIT ووقت التشغيل والمكتبات. الفكرة الأساسية ليست وجود ميزة منفردة تضاعف الأداء، بل إزالة مكاسب صغيرة متكررة: فحص حدود لم يعد ضرورياً، تخصيص ذاكرة أُلغي، قفل أو استدعاء نظامي جرى تجنبه، وحلقات أصبحت تنفذ بعدد أقل من دورات المعالج.
أهمية هذا النوع من التحسينات أن جزءاً كبيراً منه لا يتطلب تعديل كود التطبيقات أو إعادة تصميمها. فمترجم JIT يحول الوسيط IL الناتج عادة من C# وF# وVisual Basic إلى تعليمات أصلية ينفذها المعالج. وعندما ينجح في إثبات أن استدعاءً افتراضياً يمكن توجيهه إلى نوع محدد، أو أن فحصاً ما لن يفشل، يمكنه إنتاج تعليمات أقصر وتحسين فرص دمج الدوال داخل بعضها.
تحسين إزالة التجريدات
يركز جزء بارز من المادة على ما تسميه Microsoft إزالة التجريدات، أي تمكين وقت التشغيل من تجاوز الكلفة التنفيذية لبعض التجريدات التي يحتاجها المطور في تصميم البرنامج. ومن الأمثلة استدعاءات الواجهات والدوال الافتراضية، حيث قد يضطر التنفيذ التقليدي إلى تحميل مؤشرات متعددة وإجراء استدعاء غير مباشر، ما يمنع دمج الدالة المستدعاة مع الدالة الحالية.
يواصل .NET 11 تطوير أسلوب “إزالة التجريد المحروسة” أو Guarded Devirtualization. يتعرف JIT على النوع الأكثر شيوعاً أثناء التشغيل، فينشئ مساراً سريعاً لاستدعائه مباشرة، مع الإبقاء على المسار الافتراضي لضمان صحة التنفيذ إذا ظهر نوع مختلف لاحقاً. وعندما يسمح ذلك بدمج الدالة، تصبح تحسينات أخرى ممكنة، مثل نشر الثوابت وإزالة الفروع وفحوص الحدود.
يمتد العمل إلى الدوال الافتراضية العامة، وعمليات ReadyToRun وNativeAOT، والتنفيذات الافتراضية الافتراضية في الواجهات. وتشير المادة إلى أن هذه التحسينات قد تزيد حجم الكود عندما تؤدي الاستدعاءات المباشرة إلى مزيد من الدمج، لكنها تجعل منطق البرنامج مرئياً بدرجة أكبر للمحسن.
تخصيصات أقل وتأثير أخف على جامع القمامة
يستمر .NET 11 أيضاً في توسيع تحليل الهروب Escape Analysis، الذي يحاول تحديد ما إذا كان كائن أنشئ داخل دالة يتجاوز نطاقها. إذا ثبت أنه لا يخرج من ذلك النطاق، يستطيع JIT تجنب وضعه على كومة الذاكرة المُدارة، أو التخلص من التخصيص بالكامل في بعض الحالات، ما يقلل الضغط على جامع القمامة.
يعرض المصدر أمثلة على تحسين تغليف القيم القابلة للإفراغ Nullable boxing، وعلى التحليل الشرطي للهروب في تعداد المجموعات. وفي أحد القياسات، اختفى تخصيص عداده 32 بايت في حالة تعداد مجموعة مبنية من حقل مثيل، وانخفض زمن التنفيذ من 13.874 نانوثانية في .NET 10 إلى 2.674 نانوثانية في .NET 11. كما أصبحت بعض الحالات التي تستخدم قيماً عامة أو استدعاءات واجهات قادرة على تجنب تخصيصات مؤقتة بحجم 24 بايت.
هذه الأرقام تخص عمليات صغيرة جداً، ولذلك لا ينبغي قراءتها كزيادة عامة ثابتة في أداء كل تطبيق. فائدتها الأساسية أنها تكشف عن أنماط كود يمكن لوقت التشغيل تحسينها، بينما سيعتمد الأثر الفعلي على طبيعة التطبيق ومساراته الساخنة.
المفوضات ووقت التشغيل غير المتزامن
يتضمن .NET 11 تعديلات على تمثيل المفوضات في CoreCLR، من بينها إزالة حقل بحجم مؤشر واحد من كل كائن مفوض في عملية 64-بت، أي توفير 8 بايت لكل مفوض وفق المادة. كما أعيد ترتيب حقول تمثيل المفوضات في NativeAOT، ووُضعت بعض القيم المستخدمة معاً في الذاكرة لتحسين الوصول إليها على معماريات مثل Arm64.
وتقدم التدوينة كذلك بنية جديدة تحت اسم “runtime async”، تنقل جزءاً من مسؤولية تحويل أساليب async/await من مترجم C# إلى JIT ووقت التشغيل. في النموذج التقليدي ينشئ المترجم آلة حالات تحتوي على الحقول اللازمة للاستئناف، مثل المعلمات والقيم المحلية والمنتظرين وحالة التنفيذ. أما النموذج الجديد فيعتمد عقداً أصغر في IL، ثم يترك لوقت التشغيل وJIT قرارات مرتبطة بما يبقى حياً عند نقاط التعليق، وكيفية ترتيب كائنات الاستمرار، وإنشاء Task أو ValueTask المرئي خارجياً.
ما الذي يتغير عملياً؟
المغزى التحريري من هذه الجولة أن .NET 11 يراهن على تحسين الكود الموجود بقدر أكبر من إضافة واجهات برمجية جديدة. التطبيقات التي تعتمد بكثافة على الواجهات، والدوال العامة، والمفوضات، والتعداد، والعمليات غير المتزامنة قد تستفيد من دون تغييرات مصدرية مباشرة، لكن مقدار التحسن سيختلف باختلاف المعالج ونظام التشغيل وإعدادات وقت التشغيل وطبيعة الحمل.
توصي Microsoft باختبار النتائج باستخدام BenchmarkDotNet، مع تثبيت .NET 10 و.NET 11 وتشغيل الكود نفسه على الإصدارين. وتنبّه إلى أن القياسات المنشورة اختبارات دقيقة جداً، وقد تتأثر بالأجهزة والعمليات الأخرى وإعدادات البيئة. لذلك لا تكفي نتائج اختبار مصغر لاتخاذ قرار ترقية أو إثبات تحسن شامل؛ يلزم قياس أحمال التطبيق الفعلية قبل اعتماد استنتاجات أوسع.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.