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

Question

Я в процессе обновления приложения с EF1 до EF4.1 Я создал DbContext и набор POCO с помощью шаблонов «Генератор ADO.NET DbContext».

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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