http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@James Newton-King >> parsing strings is the slowest part. I think this is where CSV-style double-quote escaping is proving effective performance wise. I'm able to parse strings without a 'stack state' so I can parse simply by increment a char array, I also don't need to decode any un-escaped values and can use it as-is. Although having said that, I believe the perf cost in deserialization is also largely due to instantiating and populating objects. I'm sure you're also avoiding any runtime reflection, but you may not be using 'generic static optimizations' to also eliminate any 'Type or cached-delegate lookups' which I've also found to provide a noticeable perf increase. Feel free to examine the source code to see what I mean. The source code for the TypeSerializer is open source under the liberal new BSD Licence, quite short and hopefully easy to read, It all starts from this class: [code.google.com/.../TypeSerializer.cs](http://code.google.com/p/servicestack/source/browse/trunk/Common/ServiceStack.Text/ServiceStack.Text/TypeSerializer.cs) Although for the ultimate tips on perf optimizations I would also follow @Marc Gravell's .NET protocol buffers implementation: [http://code.google.com/p/protobuf-net/](http://code.google.com/p/protobuf-net/) As he is notorious of for doing any optimization known to .NET-land to squeeze every ounce of performance possible. http://ayende.com/4472/ravendb-performance-tweaks#comment7http://ayende.com/4472/ravendb-performance-tweaks#comment7Tue, 27 Apr 2010 13:42:24 GMTIn my experience, having written Json.NET, BSON is faster to read, JSON is faster to write. If you do want to improve JSON read performance that perf test pretty much nails it: parsing strings is the slowest part. I've made it as fast as I know how but I'm sure someone could do it faster. http://ayende.com/4472/ravendb-performance-tweaks#comment6http://ayende.com/4472/ravendb-performance-tweaks#comment6Tue, 27 Apr 2010 11:12:11 GMT@Ken Egozi Hey thx for the validation, I hope its proven useful! With all the de/serializers out there I really thought .NET was missing something that was faster, smaller, readable and more resilient than JSON and XML which is why I decided to created the hybrid JSON+CSV (aka JSV format). As you've noticed the CSV-style escaping is both quicker to parse and ends up being more readable. Basically values are not just strings or numbers (as they are in JSON) they are simply string-serialized values which are either CSV-escaped (if they contain any special chars) or not. As a bonus for controlling the source code I can ensure that it works just as good cross-platform on Mono. http://ayende.com/4472/ravendb-performance-tweaks#comment5http://ayende.com/4472/ravendb-performance-tweaks#comment5Mon, 26 Apr 2010 21:23:44 GMT@Karl I also considered using BSON at one point, the problems I had with it was that it is less human readable/writeable and you won't be able to dump it directly from the data store onto the response stream which is very useful in Ajax apps. I find BSON kind of lives in between JSON (slow, human read/writeable, version-able and interoperable) and Protocol Buffers which is very fast, fairly interoperable but more rigid and not human readable. http://ayende.com/4472/ravendb-performance-tweaks#comment4http://ayende.com/4472/ravendb-performance-tweaks#comment4Mon, 26 Apr 2010 15:13:27 GMTKarl, I am not worried that much about the parsing cost, I am more worried about the re-parsing cost, which is something different. http://ayende.com/4472/ravendb-performance-tweaks#comment3http://ayende.com/4472/ravendb-performance-tweaks#comment3Mon, 26 Apr 2010 14:44:57 GMTWould you consider using BSON instead of JSON? BSON is specifically designed for processing performance - having lengths at the start of documents (and strings) makes scanning quite efficient. I know the JSON.NET library made significant performance improvements to their BSON stuff over the last month or so. http://ayende.com/4472/ravendb-performance-tweaks#comment2http://ayende.com/4472/ravendb-performance-tweaks#comment2Mon, 26 Apr 2010 14:20:08 GMTYeah I temporarily added a value cache for my serializer as well as there are certain things like Serializing Dates which are very expensive. Obviously caching gives you an instant perf boost - unfortunately as I was trying to compare benchmarks with other serializers it was unfair to tailor my serializer against the benchmark data (i.e. the Northwind database in a tight loop) so I ended up taking it out. Also meant I no longer have to worry about running out of / cleaning up memory. http://ayende.com/4472/ravendb-performance-tweaks#comment1http://ayende.com/4472/ravendb-performance-tweaks#comment1Mon, 26 Apr 2010 10:02:03 GMT