我最近已经开始使用LINQ了很多，而且我还没有真正提到任何LINQ方法的运行时复杂性。显然，这里有许多因素在起作用，因此让我们将讨论范围限制在普通的IEnumerableLINQ
to Objects提供程序上。此外，我们假设任何Func以选择器/增幅器/等形式传入的都是廉价的O（1）操作。

它似乎很明显，所有的单次操作（Select，Where，Count，Take/Skip，Any/All，等）将是O（n）的，因为他们只需要步行的顺序一次;
尽管即使这样也会受到懒惰的影响。

对于更复杂的操作，事情变得更加模糊。集合类运算符（Union，Distinct，Except等）使用工作GetHashCode在默认情况下（据我所知），所以它似乎是合理的假设他们使用一个哈希表内，使这些操作为O（n）为好，一般。那使用的版本IEqualityComparer呢？

OrderBy需要排序，因此最有可能我们正在查看O（n log
n）。如果已经排序怎么办？如果我说OrderBy().ThenBy()并为两者提供相同的密钥怎么办？

我可以使用排序或哈希查看GroupBy（和Join）。哪有

Contains在a上将为O（n）List，但在a上将为O（1）HashSet-LINQ是否检查基础容器以查看其是否可以加快速度？

真正的问题-
到目前为止，我一直坚信作业是高效的。但是，我可以依靠吗？例如，STL容器清楚地指定了每个操作的复杂性。.NET库规范中是否对LINQ性能有任何类似的保证？

更多问题（针对评论）：并
没有真正考虑开销，但是我没想到简单的Linq-to-Objects会有很多。CodingHorror帖子谈论的是Linq-to-
SQL，在这里我可以理解解析查询并使SQL增加成本-对象提供程序也有类似的成本吗？如果是这样，使用声明性或函数语法有什么不同？