PLINQ plus long que LINQ

Bonjour,

Je possède une BDD de type SQL Server dans laquelle j'ai des auteurs et des publications. Elle est assez grosse (640Mo). Ma table AUTHOR comporte un peu plus de 900 000 auteurs.Je recherche par exemple un auteur suivant son nom, notamment s'il contient la chaine que je lui passe en paramètre. J'ai testé une version sans AsParallel(), et une avec.
Les résultats que j'obtiens sont assez bizarre!

Voici le code de ma méthode:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

public static ObservableCollection<AUTHOR> SearchAuthorsByName(String Name) { using (DataBaseDataContext Base = new DataBaseDataContext()) { var Query = (from A in Base.AUTHOR//.AsParallel() where A.AUTHOR_NAME.Contains(Name) orderby A.AUTHOR_NAME ascending select A).Take(1000);   System.Diagnostics.Stopwatch sw = System.Diagnostics.Stopwatch.StartNew();   Console.WriteLine(Query.Count());   long elapsed = sw.ElapsedMilliseconds; // or sw.ElapsedTicks   Console.WriteLine("Total query time: {0} ms", elapsed); return (new ObservableCollection<AUTHOR>(Query)); } }

---

L'appel de la méthode:

Code:

---

ObservableCollection<AUTHOR> oc = Query.SearchAuthorsByName("ha");

---

Sans AsParallel(), j'obtiens en console:

Citation:

---

125526
Total query time: 10525 ms
Appuyez sur une touche pour continuer...

---

Et avec AsParallel():

Citation:

---

98378
Total query time: 12245 ms
Appuyez sur une touche pour continuer...

---

Voila, je comprends pas pourquoi le nombre d'auteurs trouvés est différent, d'une part, et pourquoi la requête PLINQ est plus longue?!

J'ai un double coeur: AMD Turion 64 X2 Mobile Technology TL-50, 1.61GHz

Voila, si vous avez des idées, help me!

Le parallèle sur du SQL, j'y crois moyen! C'est pas fait pour...
Comprends tu ce que tu fais?
L'utilisation de LINQ est assez particulière et demande une bonne compréhension. Lorsque tu commentes ton AsParallel, tout est effectué en base (filtrage, tri, paging). Lorsque tu laisses AsParallel, il remonte toute la base en mémoire et le filtrage, tri et paging s'effectue côté mémoire. (D'ailleurs ca peut expliquer la différence)
D'autre part, avant d'essayer des solutions complexes, as tu optimisé ta table SQL ?

Bonjour

Une procédure stockée serait à mon avis bien plus performante. C'est moins sexy que du Linq, mais sur des gros volumes, il n'y a pas photo.

Citation:

---

Envoyé par Clarkgbl

Bonjour

Une procédure stockée serait à mon avis bien plus performante. C'est moins sexy que du Linq, mais sur des gros volumes, il n'y a pas photo.

---

Euh, c'est pas la question :aie: Une requête ou une proc stock auront des perfs identiques. Et ici, l'expression LINQ est assez simple pour que celle générée par Linq 2 SQL soit optimale (même si ça mérite d'être vérifié).

Pas nécessairement, le SGBD ne pourra pas réutiliser un plan existant et sur des gros volumes ça peut être très pénalisant.

Bonjour,

C'est drôle, je venais sur ce forum pour faire EXACTEMENT le même sujet oO

Je viens de constater la même chose sur le code suivant :

Code:

---

1 2	Directory.GetFiles(@"C:\Program Files (x86)", "*").Where((name) => name.First() == 'a').OrderBy((name) => name.Last());

---

est plus rapide que

Code:

---

1 2	Directory.GetFiles(@"C:\Program Files (x86)", "*").AsParallel().Where((name) => name.First() == 'a').OrderBy((name) => name.Last());

---

alors que ce dernier est "AsParallel"

Ça pourrait être logique si j'avais un simple core, mais j'ai bien un PC dual core...
Contrairement à l'auteur du topic, je n'ai pas de base SQL derrière, juste une (simple) ligne de LINQ, donc c'est pas le SGBD qui ralentit le tout...

J'ai trouvé ce bout de code sur le site suivant (bas de page) :
http://sebastiencourtois.wordpress.c...tiprocesseurs/
D'après lui ça fonctionne plutôt bien...

Des suggestions ?

Hello,

là, le plus long, c'est probablement le GetFiles, qui te ramène un array. Après, à moins que t'aies une volumétrie de malade, le tri et le filtre doivent de toutes façons prendre peanuts en temps de calcul, donc le gain à paralléliser est peanuts aussi.
Sans compter que tu fais un tri, opération non parallélisable.
Quelle est la taille de l'array retourné par GetFiles ?

Clarkgbl: les sgbd mettent en cache les plans d'exécution, et de toutes façons vu les temps dont il est question ici (de l'ordre de 10 sec), je doute que le temps de création du plan d'exécution soit non-marginal.

Citation:

---

Envoyé par Clarkgbl

Pas nécessairement, le SGBD ne pourra pas réutiliser un plan existant et sur des gros volumes ça peut être très pénalisant.

---

La réutilisation du plan d'exécution n'impacte que le temps de démarrage de la requête, donc justement pour un gros volume de données ce sera négligeable...

Attention les gars, PLINQ c'est bien, mais faut pas l'utiliser à tout bout de champs :?
Ca a des applications spécifiques, tout n'est pas parallelisable!

Citation:

---

Attention les gars, PLINQ c'est bien, mais faut pas l'utiliser à tout bout de champs
Ca a des applications spécifiques, tout n'est pas parallelisable!

---

+ 1 !
Paralléliser sur un accès disque, je ne crois pas que ce soit un gros gain de temps, car le c'est justement le disque qui va ralentir le traitement, pas les calculs du processeur.

le plinq c'est bien avec linq to object, après c'est relatif ...

Citation:

---

Envoyé par Clarkgbl

Pas nécessairement, le SGBD ne pourra pas réutiliser un plan existant et sur des gros volumes ça peut être très pénalisant.

---

si si les plans d'exécutions des requêtes sont stockées depuis 2005 il me semble
peut etre avec une durée de vie légèrement plus courte ...