Замеры 46 операций .NET: Copilot-агент добавил просадку в 16% на первом resolve DI

Спор о том, портит ли ИИ код, обычно идёт на ощущениях. Автор материала решил измерить. Он взял точку отсчёта: .NET 7 вышел за три недели до ChatGPT и стал последним релизом, написанным до эры ассистентов. С мая 2025 года в dotnet/runtime работает Copilot coding agent: к концу октября 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 в DI и кэше нашлось 113 коммитов, ни одного от агента. В окне до 11 RC агент появился: например, 3 из 11 правок горячих методов DI и кэша. Важная оговорка: коммит агента означает «PR открыт агентом», а не «написан без человека». Все PR проходят ревью людьми, а IDE-ассистент в Git вообще не виден.

Две просадки в 11 RC

Самая крупная: биндинг POCO на 50 полей вырос с 61 до 145 мкс, IOptionsSnapshot в новом scope с 52 до 136 мкс. Причина нашлась в одной строке из PR #126396 с атрибутом [ConfigurationIgnore]: property.IsDefined(...) выполняется для каждого свойства при каждом биндинге. Автор собрал биндер из исходников, заменил выражение на false и подменил одну DLL: время вернулось к 60 мкс. Основную цену даёт перегрузка с inherit: true по умолчанию. PR написал человек. Мейнтейнеры признали регрессию, но напомнили, что для горячих путей рекомендуют генератор исходников. Фикс для 11.0 пока обещан, но не гарантирован: issue привязан к milestone 12.0.0.

Вторая просадка меньше: первый resolve в DI вырос на 16,5%. Бисект по коммитам показал виновника, PR агента #124331, который чинит дедлок при циклических зависимостях через фабрики. Теперь VisitRootCache ведёт ThreadStatic HashSet, и это стоит около 0,9 мкс на первый resolve. Откат только этого PR возвращает время к уровню 10.0. Прогретые singleton, scoped и сборку провайдера коммит не задевает. Автор считает цену разумной за исправленный дедлок.

Что делать

• Если вы на 11 RC и много биндите конфигурацию, включите генератор исходников (EnableConfigurationBindingGenerator): 12 мкс против 29 мкс в 10.0.
• Вместо IOptionsSnapshot там, где не нужно обновление в рамках запроса, берите IOptionsMonitor.
• Следите за холодным стартом: он подорожал в нескольких местах.

Ограничения: это релиз-кандидат, замеры шли на одном ноутбуке, а основной трек использует сборку 11.0 на рантайме .NET 10. Вывод по ИИ скромный: ни одна из двух просадок не доказывает, что ИИ делает код хуже. Одну внёс человек, другую агент в обмен на исправление реального бага. Зато методика, в которой регрессии ловятся замерами и бисектом, ценнее любых споров.