5
LINQ方法的运行时复杂度(Big-O)有什么保证?
我最近已经开始使用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增加成本-对象提供程序是否也有类似成本?如果是这样,使用声明性或函数语法有什么不同?