Under the Hood of .NET Memory Management - Simple Talk

Chapter 5: Application-Specific Problems
With such a method, it seems natural to rewrite our original query as:
Order[] pastDueAccounts = null;
using (var context = new Context())
{
pastDueAccounts = context.Accounts
.Where(account => PastDueAccount(account))
.ToArray();
}
Listing 5.10: Rewriting the original LINQ to Entity Framework call.
This logic is actually incorrect, but it may not be caught until after an application has
been deployed and the database has had time to accumulate data. Let me explain why.
With the original method, the compiler generated an expression tree and the database
was queried for a limited amount of data. On the other hand, the refactored example
pulls all of the orders from the database and then filters them in memory. The SQL that
is generated will actually exclude the filtering restrictions, which will not be interpreted
until after the SQL is run and the results returned.
Instead of having the filter use indexes in the database and call up a small subset of the
data, no indexes will be used, and the entire contents of the table will be retrieved. For as
long as the database has a small number of records, this will not cause a problem, but it
will quickly cause substantial problems as the database volume grows.
Why do we get this behavior? The compiler implicitly converts lambda expressions to
either expression trees or delegates, depending on the context in which they are defined,
but named methods are not converted to expression trees. They therefore don't match
any of the extension methods for IQueryable, and are not incorporated into the
SQL that is sent to the database. Instead, they are treated as delegates and passed to
IEnumerable, and the delegate operates on the objects returned from the SQL call.
158