Question

Does anybody know why the NetDataContractSerializer might add "nil" entries in a serialized collection?

For example,

  <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>

Notice the three extra "JobRecord" entries and the additional element saying "hey, I know there are four nodes here, but only one of them means anything."

It seems like an odd behavior. Okay, so I could see that the NDCS peers deeply into the object graph and might be twiddling with a backing array that has a size that is greater than the number of items being serialized (think of the backing array for a List).

Is that what's going on here? Is it an artifact of the class the constructor creates to handle yield return (which is the source of the JobRecord)?

Was it helpful?

Solution

In .net collections and lists work by auto resizing when they run out of space. To make this efficient they don't just resize by 1 extra each time they run out, they use an internal algorithm to resize and leave some extra space, the aim being that they don't have to resize too often.

What you are seeing here is the collection being serialized with all of the extra space being serialized too. this is because the serialization is storing the collection exactly as it is, so when you deserialize it you get the same back, with the same number of internal space left.

If it's a List you are using you can check the internally reserved space by looking at the Capacity property.

If you want to remove any extra space before you serialize the collection you can call.

myStuff.Capacity = myStuff.Count;

This will set the available capacity to be the same as the number of items contained, so there will be no reserved space.

Unfortunately, if it's a collection you are using the Capacity isn't available, you just need to trust the collection to do it's resizing internally.

Either way, I wouldn't worry about it too much unless you need to be really really space efficient. If you do, use a fixed size array instead.

OTHER TIPS

Just a guess, but note the z:Size="4". Looks like four JobRecord entries to me, and I guess three of them = null.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top