Discussion :

[bouru42]

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 :

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

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 :

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

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

Sans AsParallel(), j'obtiens en console:

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

Et avec AsParallel():

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!

[Nathanael Marchand]

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 ?

[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.

[Guulh]

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 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é).

[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.

[Ikki_2504]

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 :

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

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

est plus rapide que

Code :

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

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 ?

[tomlev]

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...