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はO(n)ですが、A ListはO(1)ですHashSet-LINQは基礎となるコンテナーをチェックしてスピードアップできるかどうかを確認しますか? そして本当の質問-これまでのところ、私は操作が高性能であることを信じてそれを取っています。しかし、それを利用することはできますか?たとえば、STLコンテナは、すべての操作の複雑さを明確に指定します。.NETライブラリ仕様のLINQパフォーマンスについて同様の保証はありますか? その他の質問(コメントへの回答): オーバーヘッドについてはあまり考えていませんでしたが、単純なLinq-to-Objectsについてはそれほど多くあるとは思いませんでした。CodingHorrorの投稿はLinq-to-SQLについて話しており、クエリを解析してSQLを作成するとコストが追加されることを理解できます。オブジェクトプロバイダーにも同様のコストがありますか?もしそうなら、宣言構文または関数構文を使用している場合とは異なりますか?