Performance Test — JSON serializers Part II

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 on from my pre­vi­ous test which showed that the ServiceStack.Text JSON seri­al­izer was the top dog in town, I came across a lit­tle library called fastJ­son on code­plex so nat­u­rally I had to test it out and see how it com­pares to the rest!

So using my Sim­ple­SpeedTester and repeat­ing the same test as before I got the fol­low­ing results:

spacer

And graph­i­cally, this is how they look:

spacer

fastJ­son was the fastest in seri­al­iza­tion and ServiceStack.Text was fastest in dese­ri­al­iza­tion but there is very lit­tle sep­a­rat­ing the two libraries in both cases. Given a dif­fer­ent data struc­ture to serialize/deserialize you might end up with slightly dif­fer­ent results but at the end of the day the two seri­al­iz­ers have sim­i­lar per­for­mance char­ac­ter­is­tics and both are some way ahead of the other JSON seri­al­iz­ers I’ve tested.

Update 2011/11/12:

Fol­low­ing on from request by @ICooper, I’ve included Jay­Rock in the mix. How­ever, as I had trou­ble dese­ri­al­iz­ing (seri­al­iz­ing was fine) the List<int> with Jay­Rock I mod­i­fied the test object slightly:

spacer

Oth­er­wise, the con­di­tions of the test are as before, and the results are as follows:

spacer

And graph­i­cally:

spacer

Ser­viceS­tack and fastJ­son still offer by far the best per­for­mance, espe­cially with dese­ri­al­iza­tion, but this time around Ser­viceS­tack proved to be the slight bet­ter of the two, why that’s the case with an int[] instead of a List<int> is beyond me though!

Again, if you’re inter­ested in see­ing the test code your­self, you can browse it here on Code­plex.

Tweet
spacer
November 11, 2011 | theburningmonk | Tags: .Net, C#, Performance, Programming| 4 Comments »
spacer

4 Responses to “Performance Test — JSON serializers Part II”

  1. spacer Don Demsak says:
    November 11, 2011 at 1:49 pm

    Have you had a chance to play with the new System.Json seri­al­izer? It is part of the WCF Futures project wcf.codeplex.com/. If you down­load Pre­view 5, it is in there. This is also a cur­rent ver­sion of System.Json, but it is only installed as part of Sil­verlight, and is dif­fer­ent than the new one.

  2. spacer theburningmonk says:
    November 11, 2011 at 2:16 pm

    Don — not yet, I’ll give it a go tonight and include in my test and update the post with the result spacer

  3. Comparing Solr Response Sizes | Greg Sochanik says:
    March 7, 2012 at 10:46 pm

    […] con­clu­sion to this would be that because json is a widely accepted content-type, with many well known and fast de-serialising libraries, it would prob­a­bly be worth imple­ment­ing that rather than try­ing to de-serialise jav­abin. But this […]

  4. Blogs From The Geeks » Blog Archive » Comparing Solr Response Sizes - Intermittent insightful nuggets says:
    March 9, 2012 at 10:47 am

    […] con­clu­sion to this would be that because json is a widely accepted content-type, with many well known and fast de-serialising libraries, it would prob­a­bly be worth imple­ment­ing that rather than try­ing to de-serialise jav­abin. But this […]

Leave a Reply

Click here to cancel reply.

Project Euler — Problem 71 Solution
F# – Adding custom indexer and slicer to your type
 
Related searches:
november project january february december
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.