One of a new wave of buzzwords that have been made popular by the emerging breed of Ruby/Scala developers, low ceremony is usually used to describe web frameworks – if a framework is “low ceremony” then the amount of setup/configuration it requires is minimal and the central idea is that it will stay out of your work and lets you focus on your code.
Note: don’t forget to check out the Benchmarks page to see the latest round up of binary and JSON serializers.
When working with the BinaryFormatter class frequently, one of the things you notice is that it is really damn inefficient… both in terms of speed as well as the payload (the size of the serialized byte array).
Google’s Protocol Buffers format is designed to be super fast and minimizes the payload by requiring a serializable object to define ahead of time the order in which its properties/fields should be serialized/deserialized in, doing so removes the need for all sorts of metadata that traditionally need to be encoded along with the actual data.
Marc Gravell (of StackOverflow fame!) has a .Net implementation called ‘protobuf-net’, and is said to totally kick ass! As with most performance related topics, it’s hugely intriguing to me so I decided to put it to test myself :-)
Unsurprisingly, the protobuf-net serializer wins hands-down in all three categories, as you can see from the table below it is a staggering 12x faster than BinaryFormatter when it comes to serialization, with a payload size less than 15th of its counterpart’s.
One curious observation about the payload size is that, when I used a BinaryWriter to simply write every property into the output stream without any metadata, what I got back should be the minimum payload size without compression, and yet the protobuf-net serializer still manages to beat that!
BinaryFormatter with ISerializable
I also tested the BinaryFormatter with a class that implements the ISerializable interface (see below) because others had suggested in the past that you are likely to get a noticeable performance boost if you implement the ISerializable interface yourself. The belief is that it will perform much better as it removes the reliance on reflection which can be detrimental to the performance of your code when used excessively.
However, based on the tests I have done, this does not seem to be the case, the slightly better serialization speed is far from conclusive and is offset by a slightly slower deserialization speed..
If you’re interested in running the tests yourself, you can find the source code here, it uses my SimpleSpeedTester framework to orchestrate the test runs but you should be able to get the gist of it fairly easily.
As I mentioned in the post, protobuf-net managed to produce a smaller payload than what is required to hold all the property values of the test object without any meta.
I posted this question on SO, and as Marc said in his answer the smaller payload is achieved through the use of varint and zigzag encoding, read more about them here.
Since I do a fair bit of performance tests on random things that pique my interest, it’s only natural that I should make the task of carrying out these tests easier for myself, so over the weekend I put together a simple, no frills framework to do just that!
The SimpleSpeedTester project is intended to make it easier to:
It’s not a profiler! It doesn’t tell you which line of your code is taking what percentage of your CPU time or how much memory is used where. It’s intended for one thing and one thing only – help you speed test a specific piece of code/method over multiple runs, collate the results and work out the average for you so you don’t have to.
To get started, download the binaries here, reference the SimpleSpeedTester.dll in your project, and all you need is one line of code to schedule a test to be run multiple times and get a summary of the test runs:
1: // initialize a new test group
2: var testGroup = new TestGroup("Example2");
3:
4: // PlanAndExecute executes the Action delegate 5 times and returns the result summary
5: var testResultSummary = testGroup.PlanAndExecute("Test1", () => { }, 5);
6:
7: Console.WriteLine(testResultSummary);
8: /* prints out something along the line of
9: *
10: * Test Group [Example2], Test [Test1] results summary:
11: * Successes [5]
12: * Failures [0]
13: * Average Exec Time [...] milliseconds
14: *
15: */
And you’re done! Easy, right? ;-)
I’ve included a couple more examples here covering the most common use cases, more will be added as I add more functionalities.
So what are you waiting for? Go on, download it and play around with it, let me know what you think, any constructive suggestions are very welcomed!
Do you fancy a job making social games using the latest cutting-edge technologies? If your answer is yes then you are in luck, we’re looking to hire a C# developer to join our server development team and help make us one of the leading players in the social gaming space.
We are IWI, a young, small, and dynamic social games studio based in the heart of London’s west end. We focus on developing social games across multiple platforms such as Facebook, Hi5 and iOS.
You need to be an excellent team player and possess excellent knowledge of C# and WCF, knowledge/experience of cloud platforms such as Amazon Web Services or Microsoft Azure will be desirable but not essential.
We’re passionate about technology and would love to work with others who share our passion, if you have a particular interest in some technology, or have interesting hobby projects, be it at home or hosted on CodePlex, GitHub, etc. we certainly would like to hear about them!
You will have the chance to operate within a small but dedicated group of talented developers who are keen to work with cutting edge, new technologies. You will be able to make a meaningful contribution on a day-to-day basis, and have the opportunity to tackle scalability/performance challenges seldom seen in other industries.
We utilize Amazon Web Services heavily and use its many services to build massively scalable and distributed server solutions. Our current stack and toolset includes C# 4, WCF, EC2, SimpleDB (NoSql Database), RDS (managed MySql), PostSharp (AOP), Membase, an interest in at least a few of these will be a plus too.
If you’re interested in what we have to offer, then send your CV and Cover Letter to jobs@iwi.com.
NOTE: For an updated set of benchmarks, see the Benchmarks page.
For those of you who have worked with JSON data in .Net you should be familiar with the DataContractJsonSerializer class and the JavaScriptSerializer class already. Both allow you to serialize/deserialize an object to and from a piece of string in JSON format, though there are some notable differences.
Besides these two BCL (base class library) JSON serializers, there are popular third-party offering such as Json.Net and a relatively newer ServiceStack.Text which also offers its own serialization format called JSV (JSON + CSV).
It is claimed that ServiceStack.Text’s JSON serializer is 3x faster than Json.Net and 3.6x faster than the BCL JSON serializers! So, naturally, I had to test it out for myself and here’s what I found.
Assumptions/Conditions of tests
1: [DataContract]
2: public class SimpleObject
3: {
4: [DataMember]
5: public int Id { get; set; }
6:
7: [DataMember]
8: public string Name { get; set; }
9: }
Results
With these assumptions in mind, here are the average times (in milliseconds) I recorded for serialization and deserialization using each of five JSON serializers I tested:
Looking at these data, it would seem the ServiceStack.Text.JsonSerializer class offers the best speed in both serialization and deserialization cases, however the gains are much more modest than those advertised in the case of serialization. However, it really comes into its own when it comes to deserialization and the speed gains are quite impressive indeed!
Turns out I had a typo in my performance test code and I was using Json.Net for the serialization test for SimpleJson, my bad, sorry folks… So I fixed the typo and ran the tests again and updated the data and graph above with the correct data. As Prabir Shrestha pointed out, by enabled Reflection.Emit you’re able to get much better performance out of SimpleJson and the new test results reflect this as the SimpleJson test was run whilst Reflection.Emit was enabled.
