1

NetDataContractSerializerがシリアル化されたコレクションに「nil」エントリを追加する理由を誰かが知っていますか？

例えば、

  <Jobs z:Id="17">
    <_items z:Id="18" z:Size="4">
      <JobRecord z:Id="19">
        <Name z:Id="20">Job1</Name>
      </JobRecord>
      <JobRecord i:nil="true" />
      <JobRecord i:nil="true" />
      <JobRecord i:nil="true" />
    </_items>
    <_size>1</_size>
    <_version>2</_version>
  </Jobs>

3つの追加の「JobRecord」エントリと「ねえ、ここに4つのノードがあることはわかっていますが、そのうちの1つだけが何かを意味します」という追加の要素に注意してください。

奇妙な振る舞いのようです。さて、NDCSがオブジェクトグラフを深く覗き込んでいて、シリアル化されているアイテムの数よりも大きいサイズのバッキング配列をいじっている可能性があることがわかりました（リストのバッキング配列を考えてみてください）。

それはここで何が起こっているのですか？これは、コンストラクターが処理するために作成するクラスyield return（JobRecordのソース）のアーティファクトですか？

4

2 に答える 2

1

.netのコレクションとリストは、スペースが不足したときに自動サイズ変更によって機能します。これを効率的にするために、サイズがなくなるたびに1ずつサイズを変更するのではなく、内部アルゴリズムを使用してサイズを変更し、余分なスペースを残します。目的は、サイズを頻繁に変更する必要がないことです。

ここに表示されているのは、コレクションがシリアル化されており、余分なスペースもすべてシリアル化されています。これは、シリアル化によってコレクションがそのまま保存されるためです。したがって、逆シリアル化すると、同じ数の内部スペースが残ったまま、同じ結果が返されます。

使用しているリストの場合は、プロパティを確認することで、内部で予約されているスペースを確認できCapacityます。

コレクションをシリアル化する前に余分なスペースを削除したい場合は、呼び出すことができます。

myStuff.Capacity = myStuff.Count;

これにより、使用可能な容量が含まれるアイテムの数と同じになるように設定されるため、予約スペースはありません。

残念ながら、使用しているコレクションが利用できない場合は、コレクションを信頼して、内部でサイズを変更する必要があります。

いずれにせよ、あなたが本当に本当にスペース効率が良い必要がない限り、私はそれについてあまり心配しません。その場合は、代わりに固定サイズの配列を使用してください。

于 2010-03-23T17:14:08.267 に答える
0

推測ですが、に注意してくださいz:Size="4"。私には4つのエントリのように見えJobRecordますが、そのうちの3つは=だと思いますnull。

于 2010-03-23T16:55:07.527 に答える