LINQ To SQL and Visual Studio 2008 Performance Update
by David Hayden ( Microsoft MVP C# ), Filed: LINQ To SQL
Soma mentions some performance improvements in LINQ To SQL and Visual Studio 2008 in general.
I was interested in his thoughts on LINQ To SQL Performance:
“For example, with the new LINQ facility we set a goal that LINQ performance be significantly better than using a SqlDataAdaptor for the same query and competitive with using a SqlDataReader, the lightest weight interface available for retrieving data from SQL Server. In our testing, LINQ does in fact out-perform SqlDataAdaptor on almost every test case we tried, and in many of the exceptions, it is no more than 10% slower than using a SqlDataReader to accomplish the same task. Given the power of LINQ, we feel this is a very reasonable trade-off.”
This is good news, but I would love to hear more about improvements on the way the team is dealing with the chattiness of LINQ To SQL when you are prefetching a graph of objects as such:
using (NorthwindDataContext context =
new NorthwindDataContext())
{
DataLoadOptions options = new DataLoadOptions();
options.LoadWith<Customer>(c => c.Orders);
options.LoadWith<Order>(o => o.Order_Details);
context.LoadOptions = options;
IEnumerable<Customer> customers =
context.Customers.ToList<Customer>();
}
This results in way too many queries to the database which will actually hurt performance. In fact, I can probably get the SqlDataAdaptor to perform faster than LINQ To SQL by using a more optimized set of queries than what is generated natively by LINQ To SQL ( unless they have changed it ).
Obviously when you get into these scenarios where LINQ To SQL is not providing optimized queries, you can use LINQ To SQL's support for Stored Procedures:
I would prefer not to use it, however, if I don't have to :)
LINQ To SQL Tutorials:
by David Hayden ( Microsoft MVP C# ), Filed: LINQ To SQL