好的,这是我的发现经过Reflector输出一段时间后。 LINQ到对象使用WhereArrayIterator
或WhereListIterator
当它导致几乎表现得像& &运营商结合起来,连续where
谓词,但不能作为确切:
当您使用x.a==1 && x.b==1
where子句转化为Func<TSource, bool>
看起来像这样:
bool daspredicate(TSource x)
{
return x.a==1 && x.b==1
}
但是,当您使用连续的Where子句时,会有轻微的性能损失,至少源于非JITted IL-方面。下面是组合后代码的样子:
bool predicate1(TSource x)
{
return x.a==1;
}
bool predicate2(TSource x)
{
return x.b==1;
}
bool daspredicate(TSource x)
{
return predicate1(x) && predicate2(x);
}
正如您所看到的,这涉及到额外的函数调用开销。除非JIT内联函数,否则这可能相当昂贵。我相信它在这方面做得很好,但我们现在知道,如果我们自己结合我们的Where语句,JIT的工作变得更加容易,除非必要。
尽管在SQL的一面,查询是相同的。即使在执行之前,调试器也会将查询对象评估为相同的SQL语句。 Linq名称空间中我不能太过分,因为事情似乎更复杂,但由于查询是相同的,所以不应该像上面的LINQ到对象示例那样受到惩罚。
编辑:我见过多个where语句导致SQL服务器上的嵌套子查询的实例。我认为,只要能够保证安全,就坚持单个地方发言是更好的办法。
几乎重复http://stackoverflow.com/questions/1648730/when-using-linq-what-is-the-difference-between-and-multiple-where-clauses – 2009-11-04 11:27:20
我没有发现在我的搜索,但无论如何,这是LINQ到SQL的具体情况。 – 2009-11-04 11:34:23
对LINQ到对象的影响将是显而易见的,但LINQ到SQL尚不清楚。 – 2009-11-04 11:35:14