Following my recent issues with large object heap fragmentation, I've revisited some of my serializable classes. I frequently do some Xml serialization and serialize/deserialize objects containing large byte arrays.
In general I just use SerializableAttribute and do not bother about serialization details until I really need some special behaviour. Then I switch to IXmlSerializable interface and write my own serialization/deserialization code.
When manually serializing byte arrays to Xml, I prefer XmlWriter.WriteBase64(byte[] buffer, int index, int count) and XmlReader.ReadElementContentAsBase64(byte[] buffer, int index, int count) methods. This allows me to write data in chunks - very convenient.
But what happens when I just use the SerializableAttribute? Does the automatic serialization mechanism inside .NET framework writes data in chunks (like I do manually) or does it just kill large object heap by creating enormously large strings to hold whole of my byte array serialized with base64? Is the serializer efficient, or should I write my own serialization code to make sure the data is written without unnecessary overhead?
Some quick spelunking into the System.Xml.Serialization.XmlSerializer (and XmlSerializationWriter, and System.Xml.Base64Encoder) using Reflector shows that base64 byte arrays are chunked as they are converted.
"Is the serializer efficient, or should I write my own serialization code to make sure the data is written without unnecessary overhead?"
"Efficient" is not a binary condition; it is a continuum. Your real question is "Is it efficient enough for what I need?", and the answer to that is dependent on what you need. Most likely you just need to run some tests between the XmlSerializer and your custom code and see which performs better along the performance dimensions that are most important to you.
P.S. XmlSerializer does not use the SerializableAttribute; it simply serializes all public read/write properties. Only the Xml*Attributes in System.Xml.Serialization affect the XmlSerializer (along with IXmlSerializable of course).