views:

46

answers:

2

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

A: 

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

John Saunders
Whoa! That's exactly what I said in the question! You reading comprehension well! Now, *why is the NDCS doing this???*
Will
@Will: didn't realize you meant the attribute when you talked about the additional element. It's doing it so you can deserialize what you serialized, of course.
John Saunders
+1  A: 

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.

Simon P Stevens
I'm using whatever the compiler puts into the class that implements `yield return`. I didn't think it would contain an array of my return type. It still seems like a very weird behavior. I would think the serializer would trip the enumerator, grab the result and stick it into an appropriately sized array or stack, then send that down the wire.
Will
@Will. Can you post the code you're using to serialise this. I'm interested in how you're using yield.
Simon P Stevens
I think the real answer is that the NDCS peeks behind the curtains when serializing, so its actually hitting the internals of the collection and serializing those.
Will