Skip to content
Showcasing a few C# text and binary serializers for performance and size. Feel free to modify and improve.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
lib Added Avro java tool Dec 27, 2013
.gitignore Added output for ASN.1 expt on same object (it's hack for very high l… Dec 27, 2013


Showcasing a few C# text and binary serializers for performance and size. Similar in concept (but not internal design) to but for C# instead of Java. Feel free to improve and send your pull request to me.


1000 iterations per serializer, average times listed
Sorting result by size
Name                Bytes  Time (ms)
Avro (cheating)       133     0.0142
Avro                  133     0.0568
Avro MSFT             141     0.0051
Thrift (cheating)     148     0.0069
Thrift                148     0.1470
ProtoBuf              155     0.0077
MessagePack           230     0.0296
ServiceStackJSV       258     0.0159
Json.NET BSON         286     0.0381
ServiceStackJson      290     0.0164
Json.NET              290     0.0333
XmlSerializer         571     0.1025
Binary Formatter      748     0.0344

Options: (T)est, (R)esults, s(O)rt order, (S)erializer output, (D)eserializer output (in JSON form), (E)xit

Serialized via ASN.1 DER encoding to 148 bytes in 0.0674ms (hacked experiment!)


  1. The cheating tags above simply mean that unlike most serializers, Thrift/Avro code-gen their own data classes and those, not the application's existing classes, are used in transport and RPC. Most real world projects will therefore see extra processing time to copy values from their internal app logic classes into the Thrift/Avro auto-gen'd classes. In contrast, most other serializers (including Avro MSFT) use the app logic classes directly, bypassing the extra copy into the code-gen'd classes. So "cheating" simply means discarding that extra copy time. For real world performance indicators, you should look at figures WITHOUT cheating.

  2. The Avro MSFT output is larger because the automatic schema generated by the MSFT version names each field nullable/optional while the handwritten one doesn't make them optional. This saves one byte per field (optional fields take 1 extra byte). If in doubt, one can confirm the same sizes and bitstream by using InheritedEntityAvroWithNulls.avsc in the code-gen phase. If we can figure out how to suppress the generation of the optional nulls, it will be identical to the Avro project's wire format. NuGet author from MSFT for the Avro MSFT proj notified.

You can’t perform that action at this time.