Comment la performance de l'entité framework 4 vs entité cadre 3.5?

du ADO.NET Blog :

Personnalisation des requêtes - Ajout de la prise en charge des opérateurs LINQ existants, Reconnaître un plus grand ensemble de motifs avec Linq, modèle d'écriture définie fonctionne avec la capacité de utilisez-les à Linq et un certain nombre de d'autres moyens de créer et de personnaliser requêtes.

Améliorations de la lisibilité de la génération SQL - Améliorer la lisibilité, avec TSQL optimisations de performance, de la des requêtes générées pour en faire beaucoup plus facile de comprendre ce qui se passe

Ces deux points impliquent que vous pouviez voir des améliorations de la manière dont il génère votre requête de Linq.

Cependant, il est peu probable qu'un ormes puisse être en mesure d'exacerber une requête que vous avez écrite à partir de zéro, car il doit répondre à de nombreux scénarios différents, et généralement le plus courant est en panne. EF 3.5 semblait produire une jointure SQL très efficace lorsque je l'ai utilisée, probablement le meilleur que j'ai vu d'un orme, il semble que vous puissiez accueillir le SP en 4.0.

Si vous avez une procédure stockée, je suppose que c'est une grosse requête - Envoi de ce texte SQL à chaque fois que le serveur entraînera beaucoup de trafic réseau qui est une autre chose que vous pouvez ou non avoir pris en compte. Évidemment sur le même serveur ou à l'intérieur du même réseau interne, cela a «couper vos cheveux à perdre du poids» d'optimisation de style.

La réponse courte est qu'il est trop tôt pour dire. Les gars .NET se concentrent presque entièrement sur la performance jusqu'à ce que la version le 12 avril soit finalisée et localisée. En outre, ce que l'on veut dire plus vite? Plus rapide peut être considéré à bien des égards, par exemple:

• Frame-entité 4.0 a de nouvelles fonctionnalités , les améliorations de suivi de l'objet seul peuvent signifier d'énormes victoires puisque vous ne faites pas ce manuel fonctionnent vous-même ... En tout cas, au moins le développement plus rapide.
• Si cela ne fonctionnait pas du tout avant, des objets de poids plus légers avec POCO Support peut signifier beaucoup moins de mémoire décalée lorsque traiter avec beaucoup d'objets aussi. Peu importe la taille du coût des propriétés supplémentaires peuplées lors de la récupération de la DB, il y a un coût à la fois dans l'instanciation et les suivre (temps de chargement et consommation de mémoire).

  Dans votre cas spécifique, une demi-seconde est un temps long pour autre chose qu'une requête de volume très complexe ou élevé ... Avez-vous cherché à voir combien de temps est dépensé dans la base de données et comment Beaucoup de temps est passé une fois .NET a les données? Si vous passez la majeure partie de votre temps à l'extérieur de SQL, les améliorations de base des réflexions dans Net 4.0 devraient vous fournir une certaine amélioration de la vitesse ... Toutefois, si vous dépensez tout votre temps à SQL, cela ne vous aidera pas beaucoup du tout. La majeure partie de votre problème de performance peut constituer une indexation de la performance d'hydratation SQL générée et non de l'entité.

  Je suivrais le commentaire de Kane, regarde le SQL, il est en train de générer pour votre requête, est-il possible pour vous de poster cela et de la procédure stockée qui est rapide afin que nous puissions peut-être trouver là où le problème réside peut-être. ?