[Update: the results in this post about the performance of a memory stream, when changing the initial capacity are wrong. You can find the correct results in this new post.]

WCF (Windows Communication Framework) introduces additional XmlWriters for more efficient serialization of the messages send between nodes. These writers derive from the abstract XmlDictionaryWriter class and wrap the functionality of existing System.Xml. (For more information visit Justin Smith's post or watch Doug Purdy's COM326 presentation from PDC 05.

I was interested in the performance of the basic UTF-8 text writer and the binary writer for writing content heavy Xml. In this scenario an XmlDictionary won't give much benefit, since in my experience a dictionary will only reduce the size of the tags and not the actual content. More specifically I was interested in the difference in size and the speed of writing of xml files of various sizes.

On to the actual testing: I used the 138 feeds from my blogroll, that do not have a doctype in their feeds, since the XmlDictionaryWriter doesn't support writing those. After loading the feeds in an XmlDataDocument they are saved to the different streams and the size of the streams and the time it takes are written to a log-file for analyzing. Finally the whole process is repeated for a number of initial sizes for the MemoryStream (256 - 524288 in powers of 2).

The results: compression xml files makes them smaller, but it takes longer to write them.

 As you can see the difference between the text writer the binary writer are small, looking at the averages for all files.

When looking at the bytes written / tick you'll see that the binary writer is generally faster for uncompressed files smaller than 8192 bytes and negligible slower for compressed files. Another thing to notice is that the writing speed increases for uncompressed streams as the files get bigger, while it drops a little for compressed streams. The fact that the writing speed drops for the biggest files is probably caused by the mem copy which occures when the memory stream has to increase it's capacity. 

 The initial capacity doesn't seems to influence the throughput of the memorystream in a significant way, but this may be related to the data I used to test.

[Download solution for VS 2008]

Notes:

1) According to the MSDN library the compression algorithm the DeflateStream uses is the same the GZipStream uses, so performance should be similar.

2) My data is not your data; you should always do your own testing and decide of the performance and the size are right for you.