I'm performing a LINQ to Entities query (.Net 3.5 SP1) as follows:
...
var blah = from obj in myEntities.Objects
where...
select obj;
return blah.Count();
When I look at the resulting SQL in the SQL profiler, the query is calling a SELECT on a result set, not a Count. From a performance perspective, this is 10x slower than doing a handwritten ADO.Net query and getting back a scalar.
If I precompile, and put the .Count() into the precompiled function, I get an exception: "Could not load file or assembly 'System.Web.Abstractions, Version=3.5.0.0, ..." Calling .Count() after running the precompiled query is much faster than on-demand compile, but is still 1/10 the performance of an ADO.Net query.
My intuition is that most of the performance is lost in returning the result set and materializing it, instead of simply returning a scalar. Is it possible to coax this behavior out of EF 3.5?
As an aside, the query works in EF 4.0 without exception.