قياسات 46 عملية في .NET: وكيل Copilot أضاف تراجعاً بنسبة 16% عند أول resolve في DI

عادةً ما يستند الجدل حول ما إذا كان AI يفسد الشيفرة إلى الانطباعات. قرر مؤلف المادة اللجوء إلى القياس. واتخذ نقطة مرجعية واضحة: صدر .NET 7 قبل ChatGPT بثلاثة أسابيع، فكان آخر إصدار كُتب قبل عصر المساعدات. ومنذ مايو 2025، يعمل Copilot coding agent في dotnet/runtime؛ وبحلول نهاية أكتوبر 2026 كان قد فتح 1734 pull request، دُمج منها 1207.

كيف أُجريت القياسات

ثُبّتت بيئة التشغيل عند .NET 10.0.11، ولم تتغير سوى حزم NuGet من Microsoft.Extensions.*، من الإصدار 6 إلى 11، وEF Core من الإصدار 6 إلى 10. وبذلك لا تدخل تحسينات JIT وGC في النتائج. شملت التجربة 46 عملية و30 جولة، مع تشغيل كل سيناريو في عملية مستقلة على أنوية مخصصة وخلط ترتيب الإصدارات. ولا يصدر الحكم «أسرع» أو «أبطأ» إلا إذا وقع نطاق الثقة البالغ 95% بالكامل خارج عتبة 5%.

الصورة الأولية غير حاسمة. عند مقارنة الإصدار 10.0 بـ7.0، كانت 9 عمليات أسرع و13 أبطأ، فيما بقيت 10 ضمن هامش الضوضاء. تسارعت الشيفرة بعد الإحماء بنسبة 14–35%: انخفض LoggerMessage.Define من 377 إلى 244 نانوثانية، وDetectChanges على 10 آلاف كيان من 6,1 إلى 4,3 مللي ثانية. في المقابل، ارتفعت تكلفة الاستدعاءات الأولى وإنشاء الكائنات بنسبة 39–64%؛ إذ زاد أول استعلام في EF من 996 إلى 1162 مللي ثانية. هذه المقايضة مفيدة للخدمة طويلة العمر، لكنها ليست كذلك للعمليات القصيرة وبدء التشغيل البارد.

وقعت أكبر حصة من التغييرات، 19 من أصل 46، عند الانتقال إلى 8.0، أي أول إصدار بعد ChatGPT. لكن المؤلف يوضح بصدق أن القياسات تُظهر ما تغير، لا سبب تغيره. كما أن هذه الخطوة تتضمن تغيير إطار البناء المستهدف من net7.0 إلى net8.0.

أين كان الوكيل

كشف سجل Git بين v7.0.20 وv10.0.14 عن 113 commit في DI والتخزين المؤقت، ولم يكن أي منها من الوكيل. ظهر الوكيل في الفترة المؤدية إلى 11 RC؛ فعلى سبيل المثال، كان مسؤولاً عن 3 من أصل 11 تعديلاً على المسارات الساخنة في DI والتخزين المؤقت. وثمة تنبيه مهم: عبارة commit للوكيل تعني أن «الوكيل فتح PR»، لا أنه «كُتب من دون تدخل بشري». فجميع PR تخضع لمراجعة بشرية، كما أن مساعد IDE لا يظهر أصلاً في Git.

تراجعان في 11 RC

كان التراجع الأكبر في ربط POCO ذي 50 حقلاً، إذ ارتفع الزمن من 61 إلى 145 ميكروثانية، بينما زاد IOptionsSnapshot داخل scope جديد من 52 إلى 136 ميكروثانية. وتبين أن السبب سطر واحد من PR #126396 الخاص بالسمة [ConfigurationIgnore]: يُنفّذ property.IsDefined(...) لكل خاصية عند كل عملية ربط. بنى المؤلف الـ binder من الشيفرة المصدرية، واستبدل التعبير بالقيمة false، ثم استبدل ملف DLL واحداً؛ فعاد الزمن إلى 60 ميكروثانية. تأتي الكلفة الأساسية من overload الذي يستخدم inherit: true افتراضياً. كتب PR مطور بشري. أقرّ المشرفون بالتراجع، لكنهم ذكّروا بأن مولّد الشيفرة المصدرية هو الخيار الموصى به للمسارات الساخنة. وُعد بإصلاح في 11.0، لكنه غير مضمون حتى الآن؛ إذ رُبطت issue بالمرحلة 12.0.0.

أما التراجع الثاني فأصغر: ارتفع زمن أول resolve في DI بنسبة 16,5%. وكشف bisect عبر الـ commits أن المسؤول هو PR الوكيل #124331، الذي يعالج deadlock عند وجود تبعيات دورية عبر المصانع. بات VisitRootCache يحتفظ الآن بـThreadStatic HashSet، ما يضيف نحو 0,9 ميكروثانية إلى أول resolve. والتراجع عن هذا PR وحده يعيد الزمن إلى مستوى 10.0. ولا يؤثر الـ commit في singleton وscoped بعد الإحماء، ولا في بناء الـ provider. ويرى المؤلف أن هذه كلفة معقولة مقابل إصلاح deadlock.

ما العمل

• إذا كنتم تستخدمون 11 RC وتنفذون الكثير من عمليات ربط التهيئة، ففعّلوا مولّد الشيفرة المصدرية (EnableConfigurationBindingGenerator): يحقق 12 ميكروثانية مقابل 29 ميكروثانية في 10.0.
• استخدموا IOptionsMonitor بدلاً من IOptionsSnapshot عندما لا تكون هناك حاجة إلى التحديث ضمن الطلب.
• راقبوا بدء التشغيل البارد؛ فقد أصبحت كلفته أعلى في عدة مواضع.

القيود: هذا إصدار مرشح، وأُجريت القياسات على حاسوب محمول واحد، كما يستخدم المسار الرئيسي بناء 11.0 فوق بيئة تشغيل .NET 10. أما الاستنتاج بشأن AI فمتواضع: لا يثبت أي من التراجعين أن AI يجعل الشيفرة أسوأ. فقد سبّب مطور بشري أحدهما، بينما تسبب الوكيل في الآخر مقابل إصلاح خطأ حقيقي. لكن المنهجية التي تكشف التراجعات بالقياس وbisect تظل أثمن من أي جدال.