DbContext ChangeTracking убивает производительность?

Я занимаюсь обновлением приложения от EF1 до EF4.1 Я создал DbContext и набор POCOs с использованием шаблонов "ADO.NET DbContext Generator".

Когда я запрашиваю сгенерированный DbContext, часть базы данных запроса занимает 4 мс для выполнения (проверяется с помощью EF Profiler). И затем он принимает контекст около 40 секунд (словами: FORTY!), Чтобы делать все, что он делает, прежде чем он вернет результат в приложение.

EF1 обрабатывает один и тот же запрос менее чем за 2 секунды.

Отключение AutoDetectChanges, LazyLoading и ProxyGeneration выигрывает у меня 2-3 секунды.

Когда я использую метод расширения AsNoTracking(), я могу сократить общее время выполнения до 3 секунд.

Это указывает на то, что ChangeTracking является виновником.

Но ChangeTracking - это то, что мне нужно. Я должен быть в состоянии в конечном итоге сохранить все изменения без необходимости подбирать, какие объекты были изменены.

Любые идеи о том, как я могу решить эту проблему производительности?

Ответ 1

Полезен ли метод в конце этой документации? В качестве альтернативы, я избегал многих ошибок производительности, используя свободный интерфейс, чтобы декларативно указать, какие объекты в данной транзакции наверняка не изменятся или не изменится (неизменяемый или неизменяемый). Например, если сущности, которые я сохраняю, представляют собой совокупные корни, в которых корень или его сущности ссылаются на элементы "refdata", тогда эта эвристика предотвращает многие записи, потому что неизменяемые элементы не нужно отслеживать. Изменчивые элементы все записываются без проверки (слабость... одна, которая может быть или не быть приемлемой).

Я использую это с общим шаблоном репозитория именно потому, что я не хочу отслеживать изменения или реализовывать конкретную стратегию для каждого случая. Если этого недостаточно, возможно, скопируйте собственное отслеживание изменений вне контекста и добавьте объекты по мере необходимости. [/P >

Ответ 2

Не видя запроса, я не могу точно сказать, в чем проблема. Может ли это быть связано?

Почему оператор Contains() настолько резко ухудшает производительность Entity Framework?

В зависимости от используемых LINQ-операторов кажется, что EF с трудом переводит некоторые запросы в SQL. Возможно, вы столкнулись с подобной ситуацией здесь.