В.NET 4 и многоядерная среда, делает linq к sql datacontext, объект используют в своих интересах новые параллели, если мы используем DataLoadOptions. LoadWith?
Править
Я знаю, что linq к sql не параллелизирует обычные запросы. То, что я хочу знать, - когда мы указываем DataLoadOption. LoadWith, это использует распараллеливание для выполнения соответствия между каждым объектом и его sub объектами?
Пример:
using(MyDataContext context = new MyDataContext())
{
DataLaodOptions options =new DataLoadOptions();
options.LoadWith<Product>(p=>p.Category);
return this.DataContext.Products.Where(p=>p.SomeCondition);
}
генерирует следующий sql:
Select Id,Name from Categories
Select Id,Name, CategoryId from Products where p.SomeCondition
когда все продукты будут созданы, будем мы иметь a
categories.ToArray();
Parallel.Foreach(products, p =>
{
p.Category == categories.FirstOrDefault(c => c.Id == p.CategoryId);
});
или
categories.ToArray();
foreach(Product product in products)
{
product.Category = categories.FirstOrDefault(c => c.Id == product.CategoryId);
}
?
Нет, LINQ to SQL этого не делает. На стороне .NET мало что можно распараллелить. Все, что делает LINQ to SQL, - это преобразует деревья выражений в запросы SQL. SQL Server будет выполнять эти операторы SQL и может делать это параллельно.
Не забывайте, что, хотя вы можете сделать что-то подобное с вашим запросом LINQ to SQL LINQ, это плохая идея:
// BAD CODE!!! Don't parallelize a LINQ to SQL query
var q =
from customer in db.Customers.AsParallel()
where customer.Id == 5
select customer;
Хотя это дает правильные результаты, вы не получите повышения производительности, как вы надеемся на. PLINQ не может обрабатывать объекты IQueryable
. Следовательно, он будет просто обрабатывать IQueryable
как IEnumerable
(таким образом повторяя его). Он будет обрабатывать коллекцию db.Customers
параллельно и использовать несколько потоков для фильтрации клиентов. Хотя это звучит нормально, это означает, что он получит полную коллекцию клиентов из базы данных! Без конструкции AsParallel
LINQ to SQL сможет оптимизировать этот запрос, добавив в SQL WHERE id = @ID
. SQL Server мог бы использовать индексы (и, возможно, многопоточность) для получения значений.
Несмотря на то, что внутри механизма LINQ to SQL есть место для оптимизации, когда дело доходит до сопоставления сущностей с его подчиненными сущностями, в настоящее время такой оптимизации во фреймворке нет (или, по крайней мере, я не смог найти любой, использующий Reflector).