.ToLookup<TSource, TKey>を返しますILookup<TKey, TSource>。ILookup<TKey, TSource>インターフェイスも実装していますIEnumerable<IGrouping<TKey, TSource>>。
.GroupBy<TSource, TKey>を返しますIEnumerable<IGrouping<Tkey, TSource>>。
ILookup には便利な indexer プロパティがあるため、辞書のような (またはルックアップのような) 方法で使用できますが、GroupBy はできません。インデクサーなしで GroupBy を使用するのは面倒です。その後、戻りオブジェクトを参照できる唯一の方法は、それをループする (または別の LINQ 拡張メソッドを使用する) ことです。つまり、GroupBy が機能する場合は、ToLookup も同様に機能します。
このすべてから、なぜ GroupBy を気にする必要があるのかという疑問が残ります。なぜそれが存在する必要があるのですか？
なぜ私は GroupBy を気にするのでしょうか? なぜそれが存在する必要があるのですか？
10 億行のリモート データベース テーブルを表すオブジェクトに対して ToLookup を呼び出すとどうなるでしょうか。
10 億行がネットワーク経由で送信され、ルックアップ テーブルをローカルに作成します。
そのようなオブジェクトで GroupBy を呼び出すとどうなるでしょうか?
クエリ オブジェクトが作成されます。話の終わり。
そのクエリ オブジェクトが列挙されると、データベース サーバーでテーブルの分析が行われ、グループ化された結果がオンデマンドで一度にいくつか返されます。
論理的には同じものですが、それぞれのパフォーマンスへの影響は完全に異なります。ToLookup を呼び出すということは、現在 group ごとに整理された全体のキャッシュが必要であることを意味します。GroupBy を呼び出すということは、「「これらをグループ別に整理するとどうなるか」という質問を表すオブジェクトを作成していることを意味します。」
簡単な LINQ の世界の言葉で:
ToLookup()- 即時実行GroupBy()- 実行の延期この 2 つは似ていますが、異なるシナリオで使用されます。.ToLookup()すべてのグループ (ただし、グループのコンテンツではない) がすでに積極的に読み込まれている、すぐに使用できるオブジェクトを返します。一方、.GroupBy()遅延ロードされたグループのシーケンスを返します。
LINQ プロバイダーが異なれば、グループの熱心な読み込みと遅延読み込みの動作も異なる場合があります。LINQ-to-Object ではおそらくほとんど違いはありませんが、LINQ-to-SQL (または LINQ-to-EF など) では、グループ化操作はクライアントではなくデータベース サーバーで実行されるため、グループキーで追加のフィルタリングを行い（HAVING句を生成します）、すべてのグループではなく一部のグループのみを取得します。.ToLookup()すべてのアイテムが熱心にグループ化されているため、このようなセマンティクスは許可されません。