LINQ is powerful, the internal algorithm has got the power for fine tuning and PLinq is in the pipeline. That means if you will have automatic implementation of parallel LINQ for multi-core processors. Two famous quotes from Anders Hejlsberg are
"With PLinq, effectively you write the code the same way, but we arrange for it to run on multiple CPUs”
"It doesn't necessarily mean that every program is going to run six times faster, but there are classes of programs that we can make run faster without the user having to get into the nitty-gritty business of writing concurrent constructs,"
Things to remember
Ø When you will work with different set of objects and join them in your query, you have to be very careful. Especially when one of the sources is live webservice. Then the join will every time go to the WebService and create the IEnumerable<T> (the out put).
Ø While working with Linq to SQL, there are very few areas where you can fine tune the query. Rather you might be very comfortable writing super fast queries in SQL. You have no idea how Linq to SQL will create the SQL queries which will be sent to SQL Server. But you can check the outgoing SQL queries through DataContext class or Orcas debugger. I would suggest you to use stored procedure to make sure your query is super fast and well executed.
Ø Sometimes differed loading is not the accepted behavior. As it executes the query multiple times (per master data). Let’s say the scenario of Customer an Order where each customer has multiple orders. If you run a nested for loop for each customer then the query will be created and executed every time. So we have to be very careful again here if we want to avoid the differed loading by using the DataShape class.