Discussion :

[Immobilis]

Bonjour à tous,

J'ai rédigé ce petit papier pour bousculer, un peu, les certitudes au sujet des ORM et de leurs performances: http://immobilis.developpez.com/tuto...ity-framework/

N'hésitez pas à me dire ce que vous en pensez

A+

[Invité]

Salut,

J'y ai jeté un coup d'oeil vite fait !
Le sujet abordé est intéressant et l'article très bien écrit.
J'ai mis l'article dans ma liste de tutos en attente.

A première vue, j'ai l'impression que tu t'es trop acharné sur l'architecture de ton application alors qu'il s'agit juste de tester et comparer les performance de requêtes (SQL, Ling To SQL et Linq To Entities).

[Immobilis]

Salut

A première vue, j'ai l'impression que tu t'es trop acharné sur l'architecture de ton application alors qu'il s'agit juste de tester et comparer les performance de requêtes (SQL, Ling To SQL et Linq To Entities).

Choix difficile en vérité. J'ai voulu éviter que le lecteur aille trop vite au résultats. En passant par le code des fournisseurs, j'espère qu'il prendra le temps de comprendre le code.

Tu me diras si cet objectif est atteint

A+

[Invité]

Tu me diras si cet objectif est atteint

Compte sur moi.

[nah666]

Excellent article, très intéressant, pour faire des choix et connaitre les différences.

L'introduction, quoi qu'un peu longue, sur ton archi, amène bien le découpage et les besoins.

A noter également, avec une bonne abstraction on peut passer de l'un à l'autre sans (trop) de mal.

[Er3van]

Comme je te l'ai déjà dit dans un autre poste, très bon article.

Par contre à la deuxième lecture quelque chose me surprend :
L'utilisation de Linq to Entities avec des SP est plus performantes que Linq to Entities et très proche des performances de SQL(Command)...

Cela me surprend d'autant que j'ai eu les résultats très différent en faisant un benchmark sur mon application au boulot.

Pour info j'avais un programme qui en gros, supprimait 100 lignes, en rajoutait 100, et faisais ça sur environ 1 million de lignes en tout.
Les résultats que j'ai obtenu, c'est que LinqToEntitesSP donne quasiment les même performances que LinqToEntites, alors que SQL(Command) était 9 fois plus rapide.

Du coup je me pose la question de savoir s'il y a une différence de performance entre :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

db.Customers.AddObject(c);

et

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

db.AddToCustomers(c);

Et si par hasard on n'a pas, toi comme moi, des mauvaises optimisations au niveau du code...

[Immobilis]

Salut,

Histoire d'apporter un peu d'eau au moulin, par curiosité j'ai comparé les requêtes générées par le Framework lors de l'affichage de trois GridView. Chacun est connecté à une DataSource native, je n'ai fait qu'utiliser les assistants.

• Le premier est connecté à un SqlDataSource;
• Le deuxième à une EntityDataSource;
• Le troisième à une LinqDataSource.

Les requêtes pour afficher la page 8 sont dans l'ordre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM [Table_1]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
SELECT COUNT(*) AS [value]
FROM [dbo].[Table_1] AS [t0]
 
SELECT TOP (10) 
[Extent1].[Guid] AS [Guid], 
[Extent1].[TestField] AS [TestField]
FROM ( SELECT [Extent1].[Guid] AS [Guid], [Extent1].[TestField] AS [TestField], row_number() OVER (ORDER BY [Extent1].[Guid] ASC) AS [row_number]
	FROM [dbo].[Table_1] AS [Extent1]
)  AS [Extent1]
WHERE [Extent1].[row_number] > 70
ORDER BY [Extent1].[Guid] ASC

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
SELECT COUNT(*) AS [value]
FROM [dbo].[Table_1] AS [t0]
 
exec sp_executesql N'SELECT [t1].[Guid], [t1].[TestField]
FROM (
    SELECT ROW_NUMBER() OVER (ORDER BY [t0].[Guid], [t0].[TestField]) AS [ROW_NUMBER], [t0].[Guid], [t0].[TestField]
    FROM [dbo].[Table_1] AS [t0]
    ) AS [t1]
WHERE [t1].[ROW_NUMBER] BETWEEN @p0 + 1 AND @p0 + @p1
ORDER BY [t1].[ROW_NUMBER]',N'@p0 int,@p1 int',@p0=70,@p1=10

Evidemment la SqlDataSource perd car elle ramène toute la table. Que pense les DBA des deux autres sources?

A+

[iberserk]

A priori tes deux derniers gridview sont paginés d'ou les requêtes utilisant des fonctions de fenêtrage ainsi qu'un COUNT global permettant de gérer les nombre de page.

Amusant le changement de requête entre ENTITY et LINQTOSQL... même si elles donnent exactement le même résultat (page 8 avec pagesize à 10...).

Le premier gridview est paginé?

[Immobilis]

Le premier gridview est paginé?

Oui

[Invité]

Juste pour ajouter un lien intéressant => voir ici.

[Immobilis]

Re salut,

En dehors de performances intrinsèques de EF, voici un lien vers un papier au sujet de la génération des requêtes: http://labs.bewise.fr/Article/Entity...eur-aux-DBA--/

C'est très intéressant.

A+

[Invité]

Merci pour le lien.

Après lecture, Entity Framework même s'il génère des requêtes T-SQL parfois très compliquées à lire, est tout de même plus performant dans toutes les exemples cités dans l'article. Je crois que la prochaine fois qu'un DBA me sorte des trucs du genre "éviter les ORM !" je lui balance direct le lien

[iberserk]

Après lecture, Entity Framework même s'il génère des requêtes T-SQL parfois très compliquées à lire, est tout de même plus performant dans toutes les exemples cités dans l'article. Je crois que la prochaine fois qu'un DBA me sorte des trucs du genre "éviter les ORM !" je lui balance direct le lien

Pour ma part ce n'est pas les requêtes portant sur des SELECT qui me font peur... c'est les travers (quand non maîtrisé) du lazy loading mais surtout la non utilisation des SP pour les opérations INSERT/UPDATE/DELETE.

[Invité]

Pour ma part ce n'est pas les requêtes portant sur des SELECT qui me font peur...

Oh que si ! Les requêtes portant sur les SELECT sont bien à prendre en compte. Ce sont elles qui rappatrient les données dont on a besoin. Et si le développeur n'a pas pris le soin de bien de définir sa requête Linq To Entities pour ne récupérer que les données dont il a besoin cela peut jouer dans les performances. Par exemple récupérer tous les Contacts se trouvant en base pour ensuite faire un foreach là-dessus et récupérer ceux qui sont des clients est vachement plus coûteuse en mémoire et aussi en performance par rapport à une requête qui met une clause where dans la requête Linq To Entities avant exécution par EF.

c'est les travers (quand non maîtrisé) du lazy loading

Je ne vois pas trop où se trouve le problème. Le lazy loading permet le chargement à la demande et par défaut il est à True dans EF4. Si elle détériorait les performances je ne pense pas que Microsoft l'ait mis à True alors qu'il était à False dans les versions antérieures d'EF. De plus rien ne t'empêche de le remettre à False cela n'améliorera en rien les performances sauf qu'il te faudra mettra un peu de code pour charger les données de navigations c'est à dire charger manuellement ces données de navigation.

mais surtout la non utilisation des SP pour les opérations INSERT/UPDATE/DELETE.

Là encore je ne suis pas du tout d'accord avec toi. L'utilisation des SP pour les opérations INSERT/UPDATE/DELETE évite seulement la génération de la requête T-SQL par EF et le gain de temps ne dévient considérable que si tu as des centaines de milliers de lignes à insérer, supprimer ou modifier.

[B.AF]

Ce qui tues les performances, ce ne sont pas les générateurs de SQL; la plupart du temps; ce sont les scalaires et les relations faites en dépit du bon sens.

Même si on utilise un ORM; rien n'empêche de faire preuve de bon sens et d'intelligence.

Tout n'a pas à être dans la base et tout n'a pas à utiliser un ORM.

C'est un principe idiot que dire mon application accède à la donnée d'une seule et unique façon !

Le travers non maitrisé du lazy loading (qui ne devrait pas exister selon moi) c'est la génération de code. En gros, le lazy loading, c'est surtout du lazy coding. Et après ça fini en psychanalyse généralisée sur les bienfaits et les méfaits des ORM....

Le CRUD n'a pas besoin de procs stocks. De même qu'un insertion massive / bulk n'a jamais nécessité de change tracking.