Comments on: Binary versus Xml Serialization size

By: Santosh

Santosh — Thu, 20 Aug 2009 07:46:38 +0000

And i guess this alkampfer’s comparison is good with only small objects if the size of object increases, binary serializer would prove definitely better.

By: alkampfer

alkampfer — Mon, 13 Jul 2009 13:11:23 +0000

Yes you are right, the problem in finding the best way to serialize data is to understand the type of data you are storing. Basically .net serializers does not compress the serialized output, but you can post compress it with gzip. Moreover XML serialization is really differnt from binary serialization, they are different techniques.

I think that if space is your primary problem, probably it is better to resort to some form of custom serialization with some custom compress algorithm, if space is not so vital, binary serialization is surely a good and simple solution to use, since it is natively implemented by .net.

alk.

By: Ole - Andre

Ole - Andre — Mon, 13 Jul 2009 11:59:12 +0000

Is this example incomplete?

The Test class only contains a string. It is not very compactable by the the binary formatter. Consider this:

float fValue = 46573847.5;
fValue binary size: 32bit

string sValue = “46573847.5″
sValue binary size: 8×10 = 80bit (minimum)

And then you have this:
string sValue = “3″
sValue binary size: 8×1 = 8bit (minimum)

Strings can’t be compacted unless you compress them, so I think comparing these two methods using a single string is a bit wierd.

Am I in outer space?

By: alkampfer

alkampfer — Fri, 20 Mar 2009 09:31:57 +0000

I think that the problem arise because the client will try to use generated proxy class to deserialize the stream, and it does not find the original assembly on disk. What you need is to implement a SOAP extension (http://msdn.microsoft.com/en-u.....64007.aspx) that will compress your message. (maybe someone had already did it)

this will make compression completely transparent process.

alk.

By: Mohid

Mohid — Thu, 19 Mar 2009 07:18:25 +0000

Dear All,

Hope you all will be fine.

we are using Typed Datasets and Tables in our application. We get datatable from web service (application server) to bussiness layer at client side. data is becoming huge day by day and response from server to client is getting slow.
Now we want compressed data from webservice.
what we did is to get datable in web service, serialize it and compress it using system.io.compression. no issue here in web service and we get the compressed data in business layer at client. The problem / issue occur when we de-serialize after decompress the array of bytes. we got 2 different errors they are

Unable to find assembly , version, culture……
End of Stream encountered before parsing was completed

please help in this regard
Mohid

By: Again about differences about Binary versus Xml Serialization.

Again about differences about Binary versus Xml Serialization. — Sat, 01 Nov 2008 07:44:15 +0000

[...] Binary versus Xml Serialization size [...]

By: alkampfer

alkampfer — Fri, 31 Oct 2008 13:28:12 +0000

Yep, you are right, I always use binaryserialization if I need a raw way to store state of the object, but the original question was only about the size of generated serialization stream so I want to show that it is possible to obtain smaller stream.

I already told roberto that I use binary or soap if I need to use a raw storage system, not the Xml one.

Xml Serialization as you explain is a really different stuff respect to binary or soap serialization, in fact it resides in System.Xml.Serialization while the Binary and soap formatters are in System.Runtime.Serialization giving you the real idea that they are real part of the runtime.

Thanks for the comment.

alk.