web-dev-qa-db-fra.com

Analyse des performances ADO.NET et Entity Framework

Lequel donne de meilleures performances? ADO.NET ou Entity Framework.

Ce sont les deux méthodes que je veux analyser.

Méthode de test 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éthode de test Entity Framework

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

Résultat lors de la première exécution

Lorsque j'ai exécuté cette méthode ci-dessus plus de 100 fois. Le temps d'exécution moyen est indiqué dans l'image:

first result

ADO.NET n'a pris que 2 millisecondes, que Entity Framework ait pris plus de 4 millisecondes.

Résultat dans la deuxième exécution

Lorsque j'ai exécuté cette méthode encore et encore en une seule fois. Le temps d'exécution moyen entre ADO.NET et EF n'est pas beaucoup plus:

second result

Question

  1. Je pense que EF donne de très mauvaises performances lors de la première exécution. Pourquoi utilisons-nous EF?
  2. Pourquoi la deuxième exécution d'EF était plus rapide que la première exécution?
c#performanceentity-frameworkado.net
37
Niventh
  1. La première fois que EF charge des métadonnées en mémoire, cela prend du temps. Il crée une représentation en mémoire du modèle à partir du fichier edmx ou du code source si vous utilisez d'abord le code. En fait, EF est construit au sommet d'ADO.NET, il ne peut donc pas être plus rapide. Mais cela rend le développement beaucoup plus rapide. Et améliore la maintenabilité de votre code.
  2. Voir 1

Jetez un œil à l'article msdn Considérations sur les performances (Entity Framework)

56
Sergey Berezovskiy
  • 1) EF rend beaucoup de choses plus confortables lorsque vous travaillez avec des bases de données. Il se passe beaucoup de choses sous le capot que vous auriez autrement à coder manuellement.

Par exemple, l'un de mes premiers projets plus importants concernait beaucoup de données et j'ai implémenté la couche d'accès avec ADO.NET. Cela représentait quelque chose entre un quart ou même un tiers de l'ensemble du projet.

Avec mon expérience de l'EF aujourd'hui, je pourrais me débarrasser de presque tout cela! Je fais juste beaucoup de code compliqué que j'ai écrit à la main complètement inutile. Nous parlons ici de milliers de lignes.

  • 2) Deux raisons principales ici. Tout d'abord, EF est construit en plus d'utiliser ADO.NET. Cela signifie que tout ce que EF fait, ajoute plus de surcharge à tout ce que ADO ferait. Deuxièmement (très) simplement, le compilateur JIT compile le code pour la première fois juste au moment de son exécution. Cela inclut allocation de mémoire et toutes sortes d'initialisations.

Cela signifie que le code que vous exécutez plusieurs fois s'exécute beaucoup plus rapidement à partir de la deuxième fois. Si vous n'exécutez vos requêtes EF qu'une seule fois, en revanche, vous n'aurez aucun gain à ces initialisations.

Dans une application réelle, vous pourriez essayer de faire quelques optimisations comme l'utilisation de Compiled Queries . En termes de performances, cela vous aidera beaucoup car maintenant, vos requêtes n'ont plus besoin d'être préparées et compilées à chaque exécution, mais une seule fois.

12
Jens H

En travaillant chez Microsoft, j'ai écrit un article de blog comparant les performances des deux. Il semble qu'il soit en cours de migration, vous devrez donc peut-être vous rendre sur les archives Internet pour le trouver ...

Nous nous sommes beaucoup concentrés à nous assurer que le coût de performance de l'utilisation d'EF n'était pas terrible, pas parfait en V1 mais tout à fait utilisable.

Alors que près de 10 ans plus tard, l'équipe EF a fait un bon travail en améliorant les performances, en particulier en réduisant les mauvais scénarios, en concevant Entity Framework sur ADO.Net. Donc, si votre critère principal est la performance brute, vous devriez opter pour ADO.Net, avec SQL optimisé à la main.

Cela étant dit, de nombreux développeurs, autrement bons, ne créent pas le meilleur SQL; Entity Framework les isole de l'écriture des requêtes et utilise les bonnes pratiques pour produire des requêtes raisonnablement bonnes.

Le principal avantage d'Entity Framework est de fournir un niveau d'abstraction plus élevé pour travailler avec les données, isolant le développeur de l'application du modèle de données sous-jacent. Vous utiliseriez donc l'EF pour être plus productif, en écrivant moins de code d'accès aux données; vous pouvez toujours affiner des requêtes ou des opérations de données spécifiques, sans perdre l'abstraction qui facilite la programmation sur le code non critique pour les performances, qui est la plus grande partie de toute application commerciale, par exemple.

6
Bruno Guardia