c# - ado net vs entity framework performance

Análisis de rendimiento ADO.NET y Entity Framework

Question

¿Cuál da mejor rendimiento? ADO.NET o Entity Framework.

Estos son los dos métodos que quiero analizar.

Método de prueba ADO.NET

public void ADOTest()
{
Stopwatch stopwatch = Stopwatch.StartNew();
using (SqlConnection con = new SqlConnection(connection))
{
string Query = "select * from Product ";
SqlDataAdapter da = new SqlDataAdapter(Query, con);
DataSet ds = new DataSet();
con.Open();
da.Fill(ds);
DataView dv = ds.Tables[0].DefaultView;
}
stopwatch.Stop();
Console.WriteLine("ADO.NET Time Elapsed={0}", stopwatch.Elapsed);
}

Método de prueba del marco de la entidad

public void EFTest()
{
Stopwatch stopwatch = Stopwatch.StartNew();
var list = _OnlineStoreEntities.Products.ToList();
stopwatch.Stop();
Console.WriteLine("Entity Framework Elapsed={0}", stopwatch.Elapsed);
}

Resultado en la primera ejecución

Cuando ejecuté este método anterior en más de 100 veces. El tiempo promedio de ejecución se muestra en la imagen:

ADO.NET tomó solo 2 milisegundos si Entity Framework tomó más de 4 milisegundos.

Resultado en la ejecución por segunda vez

Cuando ejecuté este método una y otra vez en una sola ejecución. El tiempo promedio de ejecución entre ADO.NET y EF no es mucho más:

Pregunta

1. Creo que EF da el peor desempeño en la primera ejecución Entonces, ¿por qué usamos EF?
2. ¿Por qué la segunda ejecución de EF fue más rápida que la primera ejecución?

Answer 1

1. La primera vez que EF carga metadatos en la memoria, eso lleva un tiempo. Construye una representación en memoria del modelo a partir del archivo edmx, o del código fuente si está usando código primero. En realidad, EF es construir en la parte superior de ADO.NET, por lo que no puede ser más rápido. Pero hace que el desarrollo sea mucho más rápido. Y mejora el mantenimiento de su código.
2. Ver 1

Eche un vistazo al artículo msdn Consideraciones sobre el rendimiento (Entity Framework)

Answer 2

Mientras trabajaba en Microsoft, escribí una publicación de blog que comparaba el rendimiento de ambos. Parece que ahora está en proceso de migración, por lo que es posible que deba ir al archivo de Internet para encontrarlo ...

Nos habíamos centrado mucho en asegurarnos de que el costo de rendimiento del uso de EF no era terrible, no perfecto en V1, pero bastante útil.

Mientras que casi 10 años después, el equipo de EF ha hecho un buen trabajo mejorando el rendimiento, particularmente reduciendo los escenarios de casos malos, por diseño, el Marco de la Entidad se asienta sobre ADO.Net. Por lo tanto, si su criterio principal es el rendimiento en bruto, debe ir a ADO.Net, con SQL optimizado a mano.

Dicho esto, muchos desarrolladores buenos por lo demás, no crean el mejor SQL; Entity Framework los aísla de escribir las consultas y utiliza buenas prácticas para producir consultas razonablemente buenas.

La principal ventaja de Entity Framework es proporcionar un mayor nivel de abstracción para trabajar con datos, aislando al desarrollador de la aplicación del modelo de datos subyacente. Entonces usaría EF para ser más productivo, escribiendo menos código de acceso a datos; aún puede sintonizar consultas específicas u operaciones de datos, sin perder la abstracción que facilita la programación en el código que no es de rendimiento crítico, que es la parte más grande de cualquier aplicación comercial, por ejemplo.

Answer 3

• 1) EF hace que muchas cosas sean más cómodas cuando se trabaja con bases de datos. Hay muchas cosas bajo el capó que de otra manera tendría que codificar manualmente.

Por ejemplo, uno de mis primeros proyectos de mayor envergadura manejaba mucho con datos e implementé la capa de acceso con ADO.NET. Esto compensó algo entre un cuarto o incluso un tercio del proyecto completo.

¡Con mi experiencia de EF hoy pude deshacerme de casi todo eso! Simplemente hago innecesario el código complicado que escribí a mano. Estamos hablando de miles de líneas aquí.

• 2) Dos razones principales aquí. En primer lugar, EF se basa en el uso de ADO.NET. Esto significa que, independientemente de lo que haga EF, agregue más sobrecarga a lo que ADO haría. En segundo lugar (muy) simple, el compilador JIT compila el código por primera vez justo cuando se ejecuta. Esto incluye la asignación de memoria y todo tipo de inicializaciones.

Esto significa que el código que ejecuta varias veces se ejecuta mucho más rápido desde la segunda vez. Si ejecuta sus consultas EF solo una vez, por otro lado, no obtendrá ganancias de esas inicializaciones.

En una aplicación del mundo real, puede tratar de hacer algunas optimizaciones como usar consultas compiladas . En cuanto a rendimiento, esto te ayudará mucho porque ahora tus consultas no necesitan estar preparadas y compiladas cada vez que las ejecutas, sino solo una vez.