J'utilise LinqToSql pour interroger une base de données SQL Server CE simple et petite.Comment puis-je améliorer les performances des requêtes LinqToSql qui utilisent les propriétés EntitySet?
J'ai remarqué que toute opération impliquant des sous-propriétés est malheureusement lente.
Par exemple, si j'ai une table Customer
référencée par une table Order
, LinqToSql créera automatiquement une propriété EntitySet<Order>
. Ceci est une commodité agréable, me permettant de faire des choses comme Customer.Order.Where(o => o.ProductName = "Stopwatch")
, mais pour une raison quelconque, SQL Server CE raccroche très mal quand j'essaie de faire des choses comme ça. Une de mes requêtes, qui n'est pas si compliquée, prend 3-4 secondes à compléter.
Je peux obtenir la vitesse jusqu'à acceptable, même rapide, si je prends simplement les deux tables individuellement et les convertis en List<Customer>
et List<Order>
, puis joignez puis manuellement avec ma propre requête, mais cela nécessite beaucoup de code supplémentaire. LinqToSql génère ces propriétés EntitySet<T>
automatiquement - Je souhaite les utiliser.
Alors, comment puis-je améliorer les performances? Par exemple, existe-t-il des options DataContext
qui pourraient aider?
Remarque: Ma base de données dans son état initial est seulement environ 250K et je ne m'attends pas à ce qu'il croisse à plus de 1-2Mb. Donc, ce n'est pas comme s'il y avait beaucoup de disques.
Mise à jour
Voici les définitions de table pour l'exemple je dans ma question:
create table Order
(
Id int identity(1, 1) primary key,
ProductName ntext null,
Quantity int null
)
create table Customer
(
Id int identity(1, 1) primary key,
OrderId int null references Order (Id)
)
Jeff, merci. En regardant la requête SQL réelle m'a aidé à comprendre le problème. Il s'avère que l'une des propriétés de l'objet que je remplissais dans ma clause 'select' provoquait la mauvaise performance. Quand je l'ai commenté, cependant, cela n'a eu aucun effet sur la requête SQL! Je ne sais pas exactement pourquoi, mais je pense que c'est parce que la propriété est un 'System.Windows.Media.Brush', qui n'a pas d'équivalent SQL. Quoi qu'il en soit, si j'ai déplacé la logique pour définir le pinceau sur une boucle foreach séparée, le temps de traitement de la requête est passé de ~ 3500 ms à ~ 100 ms. Avez-vous une explication pour cela? – devuxer
C'est très intéressant. Je me demande si c'était quelque chose comme une exception interne lancée à chaque ligne quand Linq to SQL essayait de faire correspondre les types et de trouver une correspondance. Difficile à dire. Vous pourriez entrer dans les symboles du débogueur pour les méthodes LinqToSQL si vous êtes vraiment intéressé à savoir pourquoi. http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx –