A new week, a new JSON performance improvement

It’s been a few weeks since I last wrote about the aeson library for working with JSON in Haskell, but this isn’t because I’ve been idle. In fact, just tonight I put out a new release. Where the previous releases focused on parsing performance, this one focuses on encoding performance.

And the performance news is good: on real-world data, I’ve improved encoding performance by about a factor of 4. Why don’t we let the graphs do the talking.

Encoding performance


Posted in haskell, open source
6 comments on “A new week, a new JSON performance improvement
  1. Holger says:

    Thanks for the amazing work.
    Unfortunately, there seems to be a bug in the new version. If I enter “encode $ Number 200” the result is “0D”, where the old version correctly returned “200”.

  2. Holger, oops! You’re right. I swapped a “quot” and a “rem” by accident. I’ve released and added a QuickCheck test suite, so this shouldn’t happen again :-)

  3. Simon Meier says:

    Thats a very nice improvement. As you’re using the blaze-builder library, I had a go at converting your string encoding to use the ‘Write’ construction:


    Together with a function for efficiently serializing Text values using the internals of your Fusion framework, which I just exported in a local dev version


    this results in another 50% speedup on your newly released aeson- library:


    The current code is not as nice as it could be, as it defines functions that were better provided by the ‘text’ or ‘blaze-builder’ libraries. Especially, for the second patch, I’m not sure, if it should be included in aeson right now. The integration of the ‘blaze-builder’ work into ‘bytestring’ will solve these issues. However, progress is steady but not all too fast on that side.

  4. Simon, those performance improvements look great!

    I think that the fromWriteText function would be best in blaze-builder, as I can’t add it to text due to the dependency it would add on a non-platform library.

    Let me know when you release a new blaze-builder with that addition, as the added performance would be fabulous to have. What version of GHC are you benchmarking with, by the way?

  5. Simon Meier says:

    Hi Bryan,

    I’m benchmarking on a Core 2 Duo 2.2 GHz using GHC 7.0.2.

    The problem with the ‘fromWriteText’ function is that it depends on the hidden ‘Text.Fusion’ module. Hence, I first need an updated version of the ‘text’ library. Once, you expose this module, I’ll add it to blaze-builder.

    The ‘hex’ functions will have to wait with respect to blaze-builder. The plan is to incorporate them only in the new ‘bytestring’ library. Otherwise, my forces are getting spread too thin.

    BTW: Could you send me a mail when you respond? I was hoping your blogging system would do that automatically, but it is not.

  6. Selvin says:

    Hi Daniel,Your post is awesome with lot of iiatrmfonon.I am dealing with the same situation where we need to access sitecore content along with financial data from REST. REST is hosted on the main sitecore site. We have only one communication channel available between Mobile app/site to server via REST.svc. I already have setup the device with querystring(api=1). I was wondering what can be used as a layout? I have tried the .aspx with no success yet. Can you give me some more iiatrmfonon about accessing the sitecore for API from REST? Is there a way to avoid direct sitecore access from the mobile app and still get the response in xml/c#/json object? We are doing this to get the Sitecore context to gain the benefit of sitecore resources rather than just accessing the content by targeting the field values.Any help much appreciated,Regards, VP

Leave a Reply

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