LINQ-2-SQL Compiled Queries. Field vs Property?

Question

I've recently turned a LINQ-2-SQL function into a Compiled query, and I noticed some really strange behavior with it. When I store it as a static field, as per every example that I've seen here and on the rest of the web, load testing pegs the CPU at 100% for the entire duration of the test. When I do it as a static property, on the other hand, the exact same load testing script fluctuates in the 40-100% range. Why is performance so much better as a property? Anyone have an idea? As far as I can tell, the only difference between them is that the field takes more CPU than the property.

Here's the two versions:

    private static Func<WebDataContext, int, int, IEnumerable<Product>> GetProductsWithDecendentQuery
    {
        get
        {
            return CompiledQuery.Compile<WebDataContext, int, int, IEnumerable<Product>>((WebDataContext context, int left, int right) => 
                context.Taxonomies.Where(x => x.LeftNumber >= left && x.RightNumber <= right)
                .SelectMany(x => x.InventoryTaxonomies.Select(y => y.Product))
                .Distinct().Where(x => x.Status && (x.IsDropShip != true || x.Locations.Sum(y => y.Quantity) > 1))
            );
        }
    }

vs

    private static Func<WebDataContext, int, int, IEnumerable<Product>> GetProductsWithDecendentQuery =
        CompiledQuery.Compile<WebDataContext, int, int, IEnumerable<Product>>((WebDataContext context, int left, int right) => 
                context.Taxonomies.Where(x => x.LeftNumber >= left && x.RightNumber <= right)
                .SelectMany(x => x.InventoryTaxonomies.Select(y => y.Product))
                .Distinct().Where(x => x.Status && (x.IsDropShip != true || x.Locations.Sum(y => y.Quantity) > 1))
            );

Answer 1

I suspect that there is some other IO that is being performed that is not CPU dependent on the property version than on the field version. Other than the CPU utilization, do you have a comparison of the timing differences between the options?

When LINQ to SQL was in Beta and CompiledQuery was first introduced at least, the static fields were recommended in part because the compiler could detect them and optimize parts of the query at compile time rather than waiting until runtime as would be required in the case of a property. For example, there were claims that the compiler could detect the context's metadata and hard code the property setters rather than relying on a reflection approach when hydrating the objects for a static field compiled query. Rico Mariani discussed some of these optimizations at http://blogs.msdn.com/b/ricom/archive/2007/06/22/dlinq-linq-to-sql-performance-part-1.aspx . I can't say if/how these optimizations have changed in subsequent releases at this point to say for sure if that could cause the differences you are seeing.