¿Por qué la inserción de entidades en EF 4.1 es tan lenta en comparación con ObjectContext?

Question

Básicamente, inserto 35000 objetos dentro de una transacción:

using(var uow = new MyContext()){ 
    for(int i = 1; i < 35000; i++) { 
    var o = new MyObject()...; 
    uow.MySet.Add(o); 
    } 
    uow.SaveChanges(); 
} 

Esto toma siempre! Si utilizo el ObjectContex t subyacente (usando IObjectAdapter), sigue siendo lento pero tarda alrededor de 20 segundos. Parece que DbSet<> está realizando algunas búsquedas lineales, que toma una cantidad de tiempo cuadrada ...

¿Alguien más está viendo este problema?

Answer 1

Como ya se ha indicado por Ladislav en el comentario, es necesario deshabilitar la detección de cambios automática para mejorar el rendimiento:

context.Configuration.AutoDetectChangesEnabled = false; 

Esta detección de cambios está habilitado de forma predeterminada en la API DbContext.

La razón por la DbContext se comporta de manera diferente a la API ObjectContext es que muchas más funciones de la API DbContext llamarán DetectChanges internamente que las funciones de la API ObjectContext cuando se habilita la detección de cambios automática.

Here puede encontrar una lista de esas funciones que llaman DetectChanges de forma predeterminada. Ellos son:

• El Add, Attach, Find, Local, o Remove miembros en DbSet
• El GetValidationErrors, Entry, o SaveChanges miembros en DbContext
• El método Entries en DbChangeTracker

Especialmente Add llama al DetectChanges que es responsable del bajo rendimiento que experimentó.

I contraste a esto el API ObjectContext llama DetectChanges solamente automáticamente en SaveChanges pero no en AddObject y los otros métodos correspondientes se mencionó anteriormente. Esa es la razón por la cual el rendimiento predeterminado de ObjectContext es más rápido.

¿Por qué introdujeron esta detección automática de cambio predeterminada en DbContext en tantas funciones? No estoy seguro, pero parece que deshabilitarlo y llamar al DetectChanges manualmente en los puntos correctos se considera advanced and can easily introduce subtle bugs into your application so use [it] with care.

Answer 2

Pequeña prueba empírica con EF 4.3 CodeFirst:

eliminados 1000 objetos con AutoDetectChanges = true: 23 seg

eliminados 1000 objetos con AutoDetectChanges = false: 11 sec

insertados 1000 objetos con AutoDetectChanges = true: 21 sec

insertado 1000 objetos con AutoDetectChanges = falso: 13 segundos

Answer 3

Además de las respuestas que ha encontrado aquí. Es importante saber que en el nivel de la base de datos es más trabajo insertar que agregar. La base de datos debe ampliar/asignar nuevo espacio. Luego tiene que actualizar al menos el índice de clave principal. Aunque los índices también pueden actualizarse al actualizar, es mucho menos común. Si hay claves externas, tiene que leer esos índices también para asegurarse de que se mantenga la integridad referencial. Los desencadenantes también pueden desempeñar un papel, aunque pueden afectar las actualizaciones de la misma manera.

Todo el trabajo de la base de datos tiene sentido en la actividad de inserción diaria originada por las entradas de usuario. Pero si solo está cargando una base de datos existente, o tiene un proceso que genera muchas inserciones. Es posible que desee buscar formas de acelerar eso, posponiéndolo hasta el final. Normalmente, deshabilitar índices al insertar es una forma común. Hay optimizaciones muy complejas que se pueden hacer dependiendo del caso, pueden ser un poco abrumadoras.

Simplemente sepa que, en general, insertar llevará más tiempo que las actualizaciones.

Answer 4

En este .netcore 2.0 fue trasladado a:

context.ChangeTracker.AutoDetectChangesEnabled = false;