¿Por qué el código EF4 primero es tan lento cuando se almacenan objetos?

Question

Actualmente estoy investigando el uso de db4o como almacenamiento para mi aplicación web. Estoy bastante contento de lo fácil que funciona db4o. Entonces, cuando leo sobre el enfoque de Code First que me gusta, es porque la forma de trabajar con EF4 Code First es bastante similar a trabajar con db4o: crear objetos de dominio (POCO), lanzarlos a db4o y nunca mirar hacia atrás.

Pero cuando hice una comparación de rendimiento, EF 4 fue terriblemente lento. Y no pude entender por qué.

que utilice las siguientes entidades:

 

public class Recipe { private List _RecipePreparations; public int ID { get; set; } public String Name { get; set; } public String Description { get; set; } public List Tags { get; set; } public ICollection Preparations { get { return _RecipePreparations.AsReadOnly(); } }
 

public void AddPreparation(RecipePreparation preparation) 
    { 
     this._RecipePreparations.Add(preparation); 
    } 
} 
 

clase pública RecipePreparation { Nombre de la cadena pública {get; conjunto; } public String Descripción {get; conjunto; } public int Rating {get; conjunto; } public List Steps {get; conjunto; } public List Tags {get; conjunto; } public int ID {get; conjunto; }} 
 

Para probar el rendimiento I nuevo una receta, y añadir 50.000 RecipePrepations. Entonces almacenado el objeto de db4o así:

IObjectContainer db = Db4oEmbedded.OpenFile(Db4oEmbedded.NewConfiguration(), @"RecipeDB.db4o"); 
db.Store(recipe1); 
db.Close(); 

Esto toma alrededor de 13.000 (ms)

almaceno las cosas con EF4 en SQL Server 2008 (Express, localmente) como este:

cookRecipes.Recipes.Add(recipe1); 
cookRecipes.SaveChanges(); 

y que lleva 200.000 (ms)

Ahora, ¿cómo en la tierra es db4o 15 (!!!) veces más rápido que EF4/SQL? ¿Me estoy perdiendo un botón turbo secreto para EF4? Incluso creo que db4o podría hacerse más rápido? Como no inicializo el archivo de la base de datos, simplemente lo dejo crecer de forma dinámica.

Answer 1

¿Ha llamado SaveChanges()dentro de el lazo? ¡No es de extrañar que sea lento! Trate de hacer esto:

foreach(var recipe in The500000Recipes) 
{ 
    cookRecipes.Recipes.Add(recipe); 
} 
cookRecipes.SaveChanges(); 

EF espera que usted haga todos los cambios que desee y, a continuación, llamar SaveChanges vez. De esta forma, puede optimizar la comunicación de la base de datos y sql para realizar los cambios entre el estado de apertura y el estado de ahorro, ignorando todos los cambios que haya deshecho. (Por ejemplo, agregar 50 000 registros y luego eliminar la mitad de ellos, y luego presionar SaveChanges solo agregará 25 000 registros a la base de datos.)

Answer 2

El EF se destaca en muchas cosas, pero la carga masiva no es una de ellas . Si desea una carga masiva de alto rendimiento, hacerlo directamente a través del servidor de base de datos será más rápido que cualquier ORM. Si la única restricción de rendimiento de su aplicación es la carga masiva, entonces probablemente no debería usar el EF.

Answer 3

Solo para agregar a las otras respuestas: db4o normalmente se ejecuta en proceso, mientras que EF abstrae una base de datos fuera de proceso (SQL). Sin embargo, db4o es esencialmente de subproceso único.Entonces, si bien podría ser más rápido para este único ejemplo con una solicitud, SQL manejará la concurrencia (múltiples consultas, múltiples usuarios) mucho mejor que una configuración predeterminada de la base de datos db4o.

Answer 4

Quizás pueda deshabilitar Changetracking al agregar nuevos objetos, esto realmente aumentaría el rendimiento.

context.Configuration.AutoDetectChangesEnabled = false; 

Véase también Para más información: http://coding.abel.nu/2012/03/ef-code-first-change-tracking/