Performance Test – Binary serializers Part III

Yan Cui

I help clients go faster for less using serverless technologies.

Note: don’t forget to check out the Benchmarks page to see the latest round up of binary and JSON serializers.

 

Since my last round of benchmarks on binary serializers, there’s a new player in town – MessageShark, which at the time of this writing does not support serialization of fields, but offers comparable speed and payload to protobuf-net.

Using the same test objects, here’s how MessageShark compares to the other binary serializers:

Untitled_1

Untitled_2

Untitled

It’s early days for MessageShark but the signs are good, comparable serialization speed with protobuf-net and a noticeably faster deserialization speed, definitely one to keep an eye out for!


 

Whenever you’re ready, here are 4 ways I can help you:

  1. If you want a one-stop shop to help you quickly level up your serverless skills, you should check out my Production-Ready Serverless workshop. Over 20 AWS Heroes & Community Builders have passed through this workshop, plus 1000+ students from the likes of AWS, LEGO, Booking, HBO and Siemens.
  2. If you want to learn how to test serverless applications without all the pain and hassle, you should check out my latest course, Testing Serverless Architectures.
  3. If you’re a manager or founder and want to help your team move faster and build better software, then check out my consulting services.
  4. If you just want to hang out, talk serverless, or ask for help, then you should join my FREE Community.

 


6 thoughts on “Performance Test – Binary serializers Part III”

  1. Btw, I just recently checkin some changes to MessageShark and I believe that could change the result of the serialization. The change could yield a better result for MessageShark in comparison to protobuf-net.

  2. BinaryFormatter may be slow as hell but it does reconstruct arbitrarily complex object graphs correctly. OrigoDB uses BinaryFormatter by default. We also offer an IFormatter adapter for Protobuf-net but it requires you configure your types with attributes or using a RuntimeTypeModel. See https://github.com/DevrexLabs/Modules.ProtobufFormatter/blob/master/OrigoDB.Modules.Protobuf.Test/TodoModelTests.cs to understand what what kind of object graph issues need to be considered.

  3. The flexibility of BinaryFormatter is definitely useful – we’ve had to build our own plumbing when we moved to protobuf-net, but cost saving is more than significant enough to justify the added complexity. More than halved the number of servers we need to run and saving over $10,000 in EC2 bills per month.

  4. Thanks, good point! I thought it could be fair to point out that performance might not be as superior as your benchmark suggests when the graphs are complex. Some of the formatters can’t even handle cycles and multiple paths to the same object, the MessageShark C# port for instance.

  5. Also, using a contract based serializer (schema is defined separately, not included in the stream) like protobuf is more flexible when dealing with versioning. Renaming a field, class or namespace when using BinaryFormatter is a major pain best to be avoided!

  6. For sure, I have found performance of serializers to differ greatly based on payload, which is why I have always tried to tell folks to benchmark against their actual payload and built a harness to make that easier.

Leave a Comment

Your email address will not be published. Required fields are marked *