構造体とクラス

コードで100,000個のオブジェクトを作成しようとしています。それらは小さいもので、2つまたは3つのプロパティのみを持ちます。私はそれらを一般的なリストに入れ、それらがある場合、それらをループし、値aをチェックし、場合によっては値を更新しますb。

これらのオブジェクトをクラスまたは構造体として作成する方が高速/優れていますか？

編集する

a。プロパティは値のタイプです（私が考える文字列を除く？）

b。彼らは（まだわかりませんが）検証メソッドを持っているかもしれません

編集2

私は疑問に思っていました：ヒープとスタック上のオブジェクトはガベージコレクターによって同等に処理されますか、それとも動作が異なりますか？

これらのオブジェクトをクラスまたは構造体として作成する方が速いですか？

あなたはその質問への答えを決定できる唯一の人です。、両方の方法それを試して測定し、意味のある、ユーザーに焦点を当て、関連するパフォーマンスメトリックを、その後、あなたは変更が関連するシナリオで実際のユーザーに意味のある効果を持っているかどうかを知っていますよ。

構造体はヒープメモリの消費量が少なくなります（「スタック上」にあるためではなく、サイズが小さく、より簡単に圧縮できるためです）。ただし、参照コピーよりもコピーに時間がかかります。メモリ使用量や速度に関するパフォーマンスメトリックがわかりません。ここにはトレードオフがあり、あなたはそれが何であるかを知っている人です。

これらのオブジェクトをクラスまたは構造体として作成する方が良いですか？

多分クラス、多分構造。経験則として、オブジェクトが次の場合：
1.小さい
2.論理的に不変の値
3.それらがたくさんある次
に、構造体にすることを検討します。それ以外の場合は、参照型を使用します。

構造体の一部のフィールドを変更する必要がある場合は、通常、フィールドが正しく設定された新しい構造体全体を返すコンストラクタを作成することをお勧めします。これはおそらく少し遅いです（測定してください！）が、論理的にははるかに簡単に推論できます。

ヒープおよびスタック上のオブジェクトは、ガベージコレクターによって同等に処理されますか？

いいえ、スタック上のオブジェクトはコレクションのルートであるため、同じではありません。ガベージコレクターは、「スタックにあるものは生きているのか」と尋ねる必要はありません。その質問に対する答えは常に「はい、それはスタックにあります」だからです。（現在、スタックは実装の詳細であるため、オブジェクトを存続させるためにそれを信頼することはできません。ジッターは、通常はスタック値となるものを登録するなどの最適化を導入することを許可され、その後スタックに存在しません。そのため、GCはそれがまだ生きていることを認識していません。登録されたオブジェクトは、それを保持しているレジスタが再度読み取られなくなるとすぐに、その子孫を積極的に収集させることができます。

ただし、ガベージコレクターは、スタック上のオブジェクトを生きているものとして扱う必要があります。生きているものとして知られているオブジェクトを扱う方法と同じです。スタック上のオブジェクトは、存続し続ける必要があるヒープ割り当てオブジェクトを参照できるため、GCはスタックセットオブジェクトを、ライブセットを決定する目的で、ヒープ割り当てオブジェクトのように扱う必要があります。ただし、最初はヒープ上にないため、ヒープを圧縮する目的で「ライブオブジェクト」として扱われないことは明らかです。

それは明らかですか？

時にはstruct、new（）コンストラクタを呼び出す必要がなく、フィールドを直接割り当てる必要があるため、通常よりもはるかに高速になります。

例：

Value[] list = new Value[N];
for (int i = 0; i < N; i++)
{
    list[i].id = i;
    list[i].isValid = true;
}

約2〜3倍速いです

Value[] list = new Value[N];
for (int i = 0; i < N; i++)
{
    list[i] = new Value(i, true);
}

ここValueでstruct二つのフィールド（とidとisValid）。

struct Value
{
    int id;
    bool isValid;

    public Value(int i, bool isValid)
    {
        this.i = i;
        this.isValid = isValid;
    }
}

一方、アイテムを移動する必要があるか、値のタイプを選択すると、コピーが遅くなります。正確な答えを得るには、コードをプロファイルしてテストする必要があると思います。

構造体はクラスに似ているように見えるかもしれませんが、注意すべき重要な違いがあります。まず、クラスは参照型であり、構造体は値型です。構造体を使用することで、組み込み型のように動作するオブジェクトを作成し、その利点も享受できます。

クラスでNew演算子を呼び出すと、ヒープに割り当てられます。ただし、構造体をインスタンス化すると、それはスタック上に作成されます。これにより、パフォーマンスが向上します。また、クラスとは異なり、構造体のインスタンスへの参照は扱いません。構造体インスタンスを直接操作します。このため、構造体をメソッドに渡すと、参照としてではなく値によって渡されます。

詳細はこちら：

http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx

構造体の配列は連続したメモリブロックのヒープ上に表されますが、オブジェクトの配列は実際のオブジェクト自体がヒープ上の別の場所にある連続した参照ブロックとして表されるため、オブジェクトとその配列参照の両方にメモリが必要です。

この場合、それらをaに配置するList<>（そしてaをList<>配列に戻す）と、構造体を使用する方がメモリ効率が向上します。

（ただし、その大きな配列はラージオブジェクトヒープ上に配置されるため、存続期間が長いと、プロセスのメモリ管理に悪影響を与える可能性があります。また、メモリだけが考慮事項ではないことに注意してください。）

値のセマンティクスがある場合は、おそらく構造体を使用する必要があります。参照セマンティクスがある場合は、おそらくクラスを使用する必要があります。例外があり、ほとんどの場合、値のセマンティクスがある場合でもクラスの作成に傾いていますが、そこから開始します。

2番目の編集については、GCはヒープのみを扱いますが、スタックスペースよりもヒープスペースの方がはるかに多いため、スタックに物事を置くことが必ずしも成功するとは限りません。その上、構造体タイプのリストとクラスタイプのリストはどちらの方法でもヒープ上にあるので、これはこの場合は無関係です。

編集：

私は悪という言葉を有害であると考え始めています。結局のところ、クラスを可変にすることは、それが積極的に必要でない場合は悪い考えであり、可変構造を使用することを排除することはありません。ほとんどの場合悪い考えであることが多いので、それはよくない考えですが、ほとんどの場合、値のセマンティクスと一致しないため、特定のケースで構造体を使用しても意味がありません。

ネストされたプライベート構造体には、例外があり、その構造体のすべての使用は非常に限定されたスコープに制限されます。これはここでは適用されません。

本当に、「変異するので悪い構造体だ」というのは、ヒープとスタック（少なくとも、頻繁に誤解されているとしても、パフォーマンスに影響を与える）に比べてずっとましだとは思いません。「それは変化するので、それを値のセマンティクスを持つと考えるのはおそらく意味がないので、それは悪い構造です」とは少しだけ違いますが、重要なのは私が思うからです。

最善の解決策は、測定し、再度測定し、さらに測定することです。「構造体を使用する」や「クラスを使用する」などの単純化された簡単な答えを難しくする可能性がある、あなたがしていることの詳細があるかもしれません。

構造体は、本質的にはフィールドの集合体にすぎません。.NETでは、構造体がオブジェクトであるように "偽装"することが可能であり、.NETの各構造体タイプでは、ヒープオブジェクトであるオブジェクトと同じように動作する同じフィールドとメソッドを持つヒープオブジェクトタイプを暗黙的に定義します。 。そのようなヒープオブジェクト（「ボックス化」構造）への参照を保持する変数は、参照セマンティクスを示しますが、構造体を直接保持する変数は、単に変数の集約です。

構造体とクラスの混同の多くは、構造体には2つの非常に異なる使用例があり、非常に異なる設計ガイドラインが必要であるという事実に起因すると思いますが、MSガイドラインではそれらを区別しません。オブジェクトのように動作するものが必要になる場合があります。その場合、MSガイドラインはかなり妥当ですが、「16バイトの制限」はおそらく24-32に近いはずです。ただし、場合によっては、変数の集計が必要になることがあります。その目的で使用される構造体は、一連のパブリックフィールド、および場合によってはEqualsオーバーライド、ToStringオーバーライド、およびIEquatable(itsType).Equals実装。フィールドの集約として使用される構造はオブジェクトではなく、そのように見せかけるべきではありません。構造の観点から見ると、フィールドの意味は「このフィールドに最後に書き込まれたもの」に過ぎない、またはそれ以下である必要があります。追加の意味は、クライアントコードで決定する必要があります。

たとえば、変数を集計する構造体にメンバーMinimumandがあるMaximum場合、構造体自体はそのことを約束してはなりませんMinimum <= Maximum。このような構造をパラメーターとして受け取るコードは、個別の値MinimumとMaximum値が渡されたかのように動作する必要があります。要件Minimumよりも大きくないMaximumことを要件と同様に見なされるべきMinimumパラメータが別々に渡さより大きくないMaximum1。

時々考慮すべき有用なパターンは、ExposedHolder<T>クラスを以下のように定義することです：

class ExposedHolder<T>
{
  public T Value;
  ExposedHolder() { }
  ExposedHolder(T val) { Value = T; }
}

変数集約構造体があるを持っている場合List<ExposedHolder<someStruct>>、のsomeStructようなことをすることができますmyList[3].Value.someField += 7;がmyList[3].Value、他のコードに与えると、Valueそれを変更する手段を与えるのではなく、のコンテンツを与えます。対照的に、を使用した場合List<someStruct>、を使用する必要がありますvar temp=myList[3]; temp.someField += 7; myList[3] = temp;。可変クラス型を使用する場合、のコンテンツmyList[3]を外部コードに公開するには、すべてのフィールドを他のオブジェクトにコピーする必要があります。不変のクラス型または「オブジェクトスタイル」の構造体を使用した場合は、異なるものmyList[3]を除いて同様のsomeField新しいインスタンスを作成し、その新しいインスタンスをリストに格納する必要があります。

追加の注意点：多数の類似のものを格納する場合は、ネストされている可能性のある構造の配列に格納することをお勧めします。できれば、各配列のサイズを1Kから64K程度に保つようにしてください。構造体の配列は特別です。インデックスを付けると、構造体内の直接参照が生成されるため、「a [12] .x = 5;」と言うことができます。配列のようなオブジェクトを定義できますが、C＃ではそのような構文を配列と共有することはできません。

クラスを使用します。

一般的な注意について。値bを作成するときに更新しませんか？

C ++の観点からは、構造体のプロパティの変更がクラスに比べて遅くなることに同意します。しかし、ヒープではなくスタックに構造体が割り当てられているため、読み取りが高速になると思います。ヒープからデータを読み取るには、スタックからよりも多くのチェックが必要です。

まあ、やっぱりstructで行くなら、文字列を取り除き、固定サイズのcharまたはbyteバッファを使用してください。

それがre：パフォーマンスです。