theburningmonk.com

Note: Don’t for­get to check out Bench­marks page to see the lat­est round up of binary and JSON serializers.

Fol­low­ing on from my pre­vi­ous test, I have now included JsonFx and as well as the Json.Net BSON seri­al­izer in the mix to see how they match up.

The results (in mil­lisec­onds) as well as the aver­age pay­load size (for each of the 100K objects seri­al­ized) are as follows.

Graph­i­cally this is how they look:

I have included protobuf-net in this test to pro­vide more mean­ing­ful com­par­i­son for Json.Net BSON seri­al­izer since it gen­er­ates a binary pay­load and as such has a dif­fer­ent use case to the other JSON serializers.

In gen­eral, I con­sider JSON to be appro­pri­ate when the seri­al­ized data needs to be human read­able, a binary pay­load on the other hand, is more appro­pri­ate for com­mu­ni­ca­tion between applications/services.

Obser­va­tions

You can see from the results above that the Json.Net BSON seri­al­izer actu­ally gen­er­ates a big­ger pay­load than its JSON coun­ter­part. This is because the sim­ple POCO being seri­al­ized con­tains an array of 10 inte­gers in the range of 1 to 100. When the inte­ger ‘1’ is seri­al­ized as JSON, it’ll take 1 byte to rep­re­sent as one char­ac­ter, but an inte­ger will always take 4 bytes to rep­re­sent as binary!

In com­par­i­son, the pro­to­col buffer for­mat uses varint encod­ing so that smaller num­bers take a smaller num­ber of bytes to rep­re­sent, and it is not self-describing (the prop­erty names are not part of the pay­load) so it’s able to gen­er­ate a much much smaller pay­load com­pared to JSON and BSON.

Lastly, whilst the Json.Net BSON seri­al­izer offers a slightly faster dese­ri­al­iza­tion time com­pared to the Json.Net JSON seri­al­izer, it does how­ever, have a much slower seri­al­iza­tion speed.

Dis­claimers

Bench­marks do not tell the whole story, and the num­bers will nat­u­rally vary depend­ing on a num­ber of fac­tors such as the type of data being tested on. In the real world, you will also need to take into account how you’re likely to inter­act with the data, e.g. if you know you’ll be dese­ri­al­iz­ing data a lot more often than seri­al­iz­ing them then dese­ri­al­iza­tion speed will of course become less impor­tant than seri­al­iza­tion speed!

In the case of BSON and inte­gers, whilst it’s less effi­cient (than JSON) when seri­al­iz­ing small num­bers, it’s more effi­cient when the num­bers are big­ger than 4 digits.

To find out if a string con­tains a piece of sub­string, here are three sim­ple ways of going about it in C#, just to name a few:

• String.Contains
• String.IndexOf where the return value is >= 0
• Regex.IsMatch

Out of curios­ity I wanted to see if there was any notice­able dif­fer­ence in the per­for­mance of each of these options.

Given a sim­ple string “Mary had a lit­tle lamb”, let’s find out how long it takes to test whether or not this string con­tains the terms ‘lit­tle’ (the match case) and ‘big’ (the no match case) using each of these approaches, repeated over 100k times:

As you can see, Regex.IsMatch is by far the slow­est option in this test, although using RegexOptions.Compiled yielded slightly faster exe­cu­tion time. What was also inter­est­ing is that String.Contains turned out to be sig­nif­i­cantly faster than String.IndexOf.

If you take a look at the imple­men­ta­tion for String.Contains in a reflec­tor you will see:

So that explains the dif­fer­ence between the exe­cu­tion times for String.Contains and String.IndexOf, and indeed if I change the String.IndexOf test to use StringComparison.Ordinal (default is StringComparison.CurrentCulture) then I get an iden­ti­cal result to String.Contains.

With all that said, String.Contains and String.IndexOf is only use­ful for check­ing the exis­tence of an exact sub­string, but Regex is much more pow­er­ful and allows you to do so much more. How­ever, you do end up pay­ing for them even when you don’t need those addi­tional capabilities!