is 1KB in the default text encoding but only half the size in binary (554 bytes). The reasons are various:
- binary encoding knows to write int values as a one 4-bytes int and not as five 1-byte chars.
- binary does not repeat the “int” element name more than once.
- binary does not need to write known elements (e.g. Envelope, Body) but only the key in an optimized dictionary.
(click image to enlarge)
This code snippet is the one I used to send the above message in a binary format:
You can see I have built a custom binding which uses the binary encoding. Then I have instantiated my data contract class and sent it.
But take a look at this code:
It sends the same message on the wire but uses a raw xml message instead of a live object. This is common in routing scenarios, in cases where the message is manually handcrafted and in places where message is taken from an external source.
Let’s see how this message looks like in Fiddler:
its size is 577 bytes which means it has 23 extra bytes over the object-based binary message. While this seems negligible, had we sent more array elements, and had the integer values require additional digits, the difference would be very noticeable, especially for an optimized format. For example, with just 50 items in the array the second message was already 2.5 times larger the the fully optimized one.
So from where does this difference come from? when analyzing the raw messages we find two interesting differences:
- In the less optimized message the text “int” repeats a few times where in the optimized one it only appears once. As far as I understand this text here represents the array element name and not the fact that the type is an int.
- In the less optimized message the array values are written as five 1-byte chars (=5 bytes per value) whereas in the optimized message they are a one 4-byte integer (=4 bytes per value). For higher integers the difference is bigger and for long arrays the difference is huge.
Wcf binrary encoding is a popular optimization technique, especially ever since it became available to Silverlight applications. However, When untyped messages are used, binary encoded messages are less optimal than in the typed scenarios. They are still more optimal than regular text encoded messages. The same corollary can be reached for MTOM scenarios as they use the same optimization technique. If you use such messages (usually in routing scenarios) you should be aware of this and consider the different trade-offs.