9

Может кто-нибудь объяснитьПочему DbContext.SaveChanges 10x медленнее в режиме отладки

  1. Почему работать DbContext.SaveChanges ~ 10 раз медленнее в режиме отладки, чем режим производства?
  2. Есть ли способ ускорить это?

В режиме отладки моя веб-страница занимает 116 секунд для загрузки по сравнению с 15 секундами, если я запускаю проект без отладки.

Я установил инструкции трассировки и определил, что ~ 100 из 116 секунд потрачено на мой метод DbContext.SaveChanges в режиме отладки.

Запуск проекта без отладки всего 7 секунд в том же разделе.

Позвольте мне знать в комментариях, если вы хотите получить больше информации ..

Настройка проекта:

  • ASP.NET веб-страницы
  • VS2012
  • SQLServer2012
  • Entity Framework 5.0

Additiona л Информация: (Дайте мне знать в комментариях, если вам нужно больше)

  • Совокупное количество SQL запросов над методом SaveChanges составляет 20 000
  • Производство Строка соединения: Data Source = PC-DEV; Initial Catalog = 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 я профилированного базу и то, что я обнаружил, что ~ 20000 SQL команды принимают ровно то же самое время, является ли запустить проект в отладке или продуктивном режиме. (0 мс на команду).

Однако абсолютная разница во времени в среднем между командами 20 000 составляет 5 мс в режиме отладки.

В соответствии с режимом производства средняя разница во времени по сравнению с набором команд составляет 0,3 мс.

Это приблизительная разница в производительности в 10 раз и изолирует инфраструктуру сущности как то, что занимает дополнительное время в режиме отладки.

Есть ли способ настроить отладочную сборку таким образом, чтобы на EntityFramework можно было ссылаться без флагов отладки?

И если бы я каким-то образом смог достичь производительности с помощью некоторой магии компилятора, что бы я потерял с точки зрения возможностей отладки? В настоящее время я не могу войти в код инфраструктуры сущности, поэтому я не думаю, что я пропущу что-нибудь.

Спасибо!

+0

Как строка подключения выглядеть, при отладке? – RealityDysfunction

+0

@RealityDysfunction обновил вопрос с помощью строки в режимах производства и отладки. – Jesse

+0

У вас есть «Включить только мой код» в VS? В меню «Отладка» -> «Параметры» и «Настройки» -> «Общие» -> «Включить только мой код». Может быть, у вас есть этот флажок, и VS пытается отладить EF? – Tombala

ответ

18

Whohoo!

Итак, причина, по которой режим отладки был исключительно медленным, заключался в том, что Intellitrace Visual Studio записывал каждое событие ADO.NET (все 20 000 из них), сгенерированное Entity Framework.

So Tools-> Options -> IntelliTrace и Снимите флажок «Включить IntelliTrace» исправил проблему.

Или можно также просто отфильтровать ADO.NET события, перейдя в меню Инструменты> Параметры -> IntelliTrace -> IntelliTrace События и снимите флажок ADO.NET

Спасибо за предложения каждого.

раздел здесь говорит о Will Intellitrace slow down my app

Как Filter IntelliTrace Events

+1

Это применимо только к Visual Studio Ultimate. – Vlad

1

Для EF существует несколько performance considerations, и известно, что compared для многих других орм, операции могут быть медленнее, чем ожидалось/желательно для орма.

(1-й) при запуске отладки всегда будет медленнее и (2-й) первый запуск после того, как здание будет всегда медленнее.

Все это может зависеть от сложности вашей модели. Попробуйте capture the T-SQL statements using SQL Profiler.

Смежные вопросы