JSON (de)serialization enhancements

[vipero07]

Stack Overflow developed their own JSON (de)serializer that is almost on par with protobuf-net speeds. It is called JIL and leverages IL for speedy (de)serialization.

Here are a few articles regarding the speed differences.
http://kevinmontrose.com/2013/11/13/jil-serializing-json-really-really-quickly/
http://blog.developers.ba/replace-json-net-jil-json-serializer-asp-net-web-api/
http://rushfrisby.com/improving-webapi-performance-with-jil-and-protocol-buffers/

[RehanSaeed]

Thanks for the suggestion. I'm aware of JIL, my understanding is that it is blazingly fast but has some limitations (not that I can remember what they were) but that makes sense as JSON.NET has to work for everyone and provide support for everything.

I guess that you are suggesting adding a JIL based media type formatter, is that correct? That's a good idea for an API, maybe not for a website as it wouldn't be used much. It would require a new NuGet package because of the added dependency.

[RehanSaeed]

Added to the TODO list.

[vipero07]

I thought I followed up with a response but apparently not. Yes it would be great to be able to select (during the initialization of the project) the media type formatters a user would like to include.

I think the limitations presented with using JIL is that the initial request is slower than that of JSON.NET.

From the git

The first time Jil is used to serialize a given configuration and type pair, it will spend extra time building the serializer. Subsequent invocations will be much faster, so if a consistently fast runtime is necessary in your code you may want to "prime the pump" with an earlier "throw away" serialization.

Essentially requiring large lists of deserialized or serialized objects to be primed for best effect. As a result it shouldn't be the default because not all devs would know this. I'm not sure if this has implications that the serializer should be a singleton or what though.

[RehanSaeed]

Thanks for pointing that out. It seems it's not as simple as just switching out the serializer. We would have to add some kind of warmup phase.

I know that JSON.NET has started to do some work on performance in version 8+. In particular in reusing arrays to reduce object allocations. I would be interested to see what the performance is like after these changes. Perhaps there is a benchmark somewhere.

[vipero07]

The majority of the benchmarks I've seen do not account for "priming the pump" so the two end up having very similar performances. But it would be interesting to see version 8+ benchmarks compared to JIL when JIL is set up properly.