LINQは、低レベルのデータ反復手法よりもはるかに多くの処理サイクルとメモリを必要としますか？

バックグラウンド

私は最近、.NETスタックを使用するポジションの厳しい技術面接に耐える過程にあります。その中には、このような愚かな質問や、より有効な質問が含まれています。最近、有効な問題に遭遇しましたが、確認するにはここのコミュニティに確認したいと思います。

面接官から、テキストドキュメント内の単語の頻度を数え、結果をランク付けする方法を尋ねられたとき、私は

1. ストリームオブジェクトを使用して、テキストファイルを文字列としてメモリに配置します。
2. 句読点を無視しながら、文字列をスペース上の配列に分割します。
3. 配列とに対してLINQを使用.GroupBy()し.Count()、次にOrderBy()カウントと言います。

私は2つの理由でこの答えを間違えました：

1. テキストファイル全体をメモリにストリーミングすると、障害が発生する可能性があります。それが完全な百科事典だったらどうでしょうか？代わりに、一度に1つのブロックをストリーミングして、ハッシュテーブルの作成を開始します。
2. LINQは高すぎるため、必要な処理サイクルが多すぎます。代わりにハッシュテーブルを作成する必要があり、反復ごとに、存在しない場合にのみハッシュテーブルに単語を追加してから、カウントをインクリメントしました。

最初の理由は、まあ、理にかなっているようです。しかし、2番目は私にもっと休止を与えます。LINQのセールスポイントの1つは、ハッシュテーブルのような下位レベルの操作を単純に抽象化することですが、ベールの下では、同じ実装です。

質問

抽象化されたメソッドを呼び出すためのいくつかの追加の処理サイクルを除いて、LINQは、特定のデータ反復タスクを実行するために、低レベルのタスク（ハッシュテーブルの作成など）よりもはるかに多くの処理サイクルを必要としますか？

この回答の主な弱点は、Linqの使用が少なく、特定の演算子が選択されていることです。GroupBy各要素を受け取り、それをキーと値に射影し、ルックアップに入ります。つまり、すべての単語がルックアップに何かを追加します。

素朴な実装で.GroupBy(e => e)は、すべての単語のコピーがソースマテリアルに保存され、最終的なルックアップは元のソースマテリアルとほぼ同じ大きさになります。値を.GroupBy(e => e, e => null)予測していても、小さな値の大きなルックアップを作成しています。

ここで必要なのは、必要な情報のみを保持する演算子です。これは、各単語の1つのコピーと、それまでのその単語の数です。そのために使用できますAggregate：

words.Aggregate(new Dictionary<string, int>(), (counts, word) => 
{
    int currentCount;
    counts.TryGetValue(word, currentCount);
    counts[word] = currentCount + 1;
    return counts;
} 

ここから、これを速くするためにいくつかの方法があります。

1. 分割中に多数の文字列を作成する代わりに、元の文字列と単語を含むセグメントを参照する構造体を渡し、一意のキーであることが判明した場合にのみセグメントをコピーすることができます
2. Parallel Linqを使用して複数のコアに集約し、結果を結合します。これは、これを手作業で行うために必要な脚の作業と比較すると、些細なことです。

逃げ場が狭かったと思いますが、面接官は彼が何について話しているのか本当に知りませんでした。さらに悪いことに、彼は「正しい」答えがあると信じています。もし彼があなたが働きたい人であったなら、私は彼があなたの最初の答えを取り、あなたがそれを選んだ理由を見つけ、それから彼がそれに問題を見つけることができればそれをより良くするようにあなたに挑戦することを期待します。

LINQは魔法のように見えるので、人々を怖がらせます。それは実際には非常に単純です（非常に単純なので、それを思いつくには天才である必要があります）

var result = from item in collection where item=>item.Property > 3 select item;

にコンパイルされます：

IEnumerable<itemType> result = collection.Where(item=>item.property >3);

（もし構文が間違っている場合は叫ばないでください。それは真夜中過ぎで、私はベッドにいます:)）

ラムダを使用するIEnumerableの拡張メソッドはどこにありますか。ラムダは単に（この場合）デリゲートにコンパイルされます。

bool AMethod(ItemType item)
{
    return item.property >3;
}

Whereメソッドは、AMethodがtrueを返す項目のすべてのインスタンスを、返されるコレクションに追加するだけです。

foreachを実行して、ループ内のすべての一致するアイテムをコレクションに追加するよりも遅い理由はありません。実際には、Where拡張メソッドがおそらくまさにそれを行っています。真の魔法は、代替のwhere基準を注入する必要がある場合に発生します。

上記のコメントで述べたように、リンクされている例のいくつかは非常に間違っています。そして、問題を引き起こすのはこの種の誤った情報です。

最後に、面接でチャンスが与えられた場合、次のように言うことができます。

• LINQは読みやすく、特に興味深い予測とグループ化の導入を開始する場合に便利です。読みやすいコードは、勝利であるコードを維持するのが簡単です。

• それが実際にボトルネックである場合、パフォーマンスを測定し、それを別のものに置き換えることは本当に簡単です。