Почему DbContext.SaveChanges 10x медленнее в режиме отладки
Может кто-нибудь объяснить
- Почему DbContext.SaveChanges запускает ~ 10x медленнее в режиме отладки, чем в рабочем режиме?
- Есть ли способ ускорить это?
В режиме отладки моя веб-страница занимает 116 секунд для загрузки против 15 секунд, если я запускаю проект без отладки.
Я установил инструкции трассировки и определил, что ~ 100 из 116 секунд потрачено в моем методе DbContext.SaveChanges в режиме отладки.
Запуск проекта без отладки всего 7 секунд в том же разделе.
Сообщите мне в комментариях, если вам нужна дополнительная информация.
Настройка проекта:
- Веб-страница ASP.NET
- VS2012
- SQLServer2012
- Entity Framework 5.0
Дополнительная информация: (дайте мне знать в комментариях, если вам нужно больше)
- Совокупное количество запросов sql по методу SaveChanges составляет 20 000
- Производственная строка подключения: источник данных = PC-DEV; начальный каталог = aspnet-2013-06-04; Integrated Security = True; MultipleActiveResultSets = True; имя приложения = EntityFrameworkMUE
- Строка отладки подключения: источник данных = PC-DEV; начальный каталог = aspnet-2013-06-04; Integrated Security = True; MultipleActiveResultSets = True; имя приложения = EntityFrameworkMUE
- Я также испытал такую же относительную производительность с LocalDB, что и база данных поддержки
Update:
Как было предложено @ruionwriting, я профилировал базу данных, и я обнаружил, что команды ~ 20 000 sql принимают ровно то же самое время, независимо от того, выполняется ли проект в режиме отладки или производства. (0 мс на команду).
Однако абсолютная разница во времени в среднем между 20 000 командами составляет 5 мс в режиме отладки.
В отличие от режима производства средняя разность во времени по сравнению с набором команд составляет 0,3 мс.
Это приблизительная разница в производительности в 10 раз и изолирует инфраструктуру сущности как то, что занимает дополнительное время в режиме отладки.
Есть ли способ настроить сборку отладки, чтобы на EntityFramework можно было ссылаться без флагов отладки?
И если бы я каким-то образом добился производительности обратно через некоторую магию компилятора, что бы я потерял с точки зрения возможностей отладки? В настоящее время я не могу войти в код рамки сущности, поэтому я не думаю, что что-то пропустил.
Спасибо!
Ответы
Ответ 1
Whohoo!
Итак, причина, по которой режим отладки был исключительно медленным, заключался в том, что Visual Studio Intellitrace записывала каждое событие ADO.NET(все 20 000 из них), сгенерированное Entity Framework.
Итак, Инструменты- > Параметры → IntelliTrace и Снимите флажок "Включить IntelliTrace" .
Или можно также просто отфильтровать события ADO.NET, выбрав Инструменты- > Параметры → IntelliTrace → IntelliTrace Events и снимите флажок ADO.NET
Спасибо за все предложения.
В разделе здесь говорится о Будет ли Intellitrace замедлять мое приложение
Как Фильтровать события IntelliTrace
Ответ 2
Существует несколько соображений производительности для EF, и он знал, что сравним со многими другими ормами, операции могут быть медленнее, чем ожидалось/требовалось для orm.
(1-е) при запуске отладки всегда будет медленнее и (2-й) сначала запускается после того, как построение будет всегда медленнее.
Все это может зависеть от сложности вашей модели. Попробуйте захватить инструкции T-SQL с помощью SQL Profiler.
Ответ 3
Как указано в комментариях, данный ответ работает только для Visual Studio Ultimate.
Начиная с VS2019 (и, вероятно, большинства других версий), решение заключается в следующем:
Инструменты> Параметры> Отладка> Общие
Затем снимите флажок "Включить средства диагностики при отладке".
Конечно, вы потеряете все диагностические биты и биты, но это значительно ускоряет Entity Framework, если вы этого хотите.