DbContext ChangeTracking mata el rendimiento?

Question

Estoy en proceso de actualizar una aplicación de EF1 a EF4.1 Creé un DbContext y un conjunto de POCO utilizando las plantillas "ADO.NET DbContext Generator".

Cuando consulto el DbContext generado la parte de la base de datos de la consulta tarda 4ms en ejecutarse (validada con EF Profiler). Y luego toma el contexto unos 40 segundos (en palabras: ¡CUARENTA!) Para hacer lo que sea que haga antes de devolver el resultado a la aplicación.

EF1 maneja la misma consulta en menos de 2 segundos.

Desactivando AutoDetectChanges, LazyLoading y ProxyGeneration me gana 2-3 segundos.

Cuando uso el método de extensión AsNoTracking() puedo reducir el tiempo total de ejecución a aproximadamente 3 segundos.

Eso indica que ChangeTracking es el culpable.

Pero ChangeTracking es lo que necesito. Debo poder eventualmente persistir todos los cambios sin tener que seleccionar manualmente qué entidades fueron modificadas.

Alguna idea de cómo podría resolver ese problema de rendimiento?

Answer 1

¿Es útil la técnica al final de este documentation? Alternativamente, he evitado muchas de las trampas en el rendimiento usando una interfaz fluida para declarar declarativamente qué entidades en una transacción dada seguramente no cambiarán frente a las que podrían cambiar (inmutables vs. inmutables). Por ejemplo, si las entidades que guardo son raíces agregadas en las que la raíz o sus entidades hacen referencia a elementos "refdata", esta heurística evita muchas escrituras porque no es necesario rastrear los elementos inmutables . Los elementos mutables se escriben sin control (una debilidad ... Uno que puede o no ser aceptable).

Estoy usando esto con un patrón de repositorio genérico precisamente porque no quiero rastrear cambios o implementar una estrategia específica para cada caso. Si eso no es suficiente, quizás establezca su propio seguimiento de cambios fuera del contexto y agregue entidades según sea necesario.

Answer 2

Sin ver la consulta, no puedo decir con certeza cuál será el problema. ¿Podría esto estar relacionado?

Why does the Contains() operator degrade Entity Framework's performance so dramatically?

Dependiendo de los operadores están utilizando LINQ, parece que EF tiene un tiempo difícil la conversión de algunas consultas a SQL. Quizás estás enfrentando una situación similar aquí.