Performance Test – Binary serializers Part III

Yan Cui

I help clients go faster for less using serverless technologies.

This article is brought to you by

The real-time data platform that empowers developers to build innovative products faster and more reliably than ever before.

Learn more

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. Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
  2. Do you want to know how to test serverless architectures with a fast dev & test loop? Check out my latest course, Testing Serverless Architectures and learn the smart way to test serverless.
  3. I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
  4. Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.

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 *