http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660BSON, No, I didn't know about that, thanks, I'll try it. http://ayende.com/4477/optimizing-expensive-calls#comment17http://ayende.com/4477/optimizing-expensive-calls#comment17Wed, 05 May 2010 15:57:24 GMTThank you http://ayende.com/4477/optimizing-expensive-calls#comment16http://ayende.com/4477/optimizing-expensive-calls#comment16Mon, 03 May 2010 08:20:43 GMTThomas, This is dotTrace, a wonderful tool from JetBrains http://ayende.com/4477/optimizing-expensive-calls#comment15http://ayende.com/4477/optimizing-expensive-calls#comment15Mon, 03 May 2010 06:19:06 GMTWhat tool do you use, for creating the "report" with the expensive calls? http://ayende.com/4477/optimizing-expensive-calls#comment14http://ayende.com/4477/optimizing-expensive-calls#comment14Mon, 03 May 2010 06:17:58 GMTProbably you need to process the json only because you have to make sure ID and Version attributes are set. If so, you could just copy the doc from json reader to a json writer, adding id and version if necessary. http://ayende.com/4477/optimizing-expensive-calls#comment13http://ayende.com/4477/optimizing-expensive-calls#comment13Sat, 01 May 2010 11:51:57 GMTVery interesting NewtonSoft.Json is faster than BinaryFormatter. http://ayende.com/4477/optimizing-expensive-calls#comment12http://ayende.com/4477/optimizing-expensive-calls#comment12Sat, 01 May 2010 04:51:44 GMTCan you serialize many objects at once with threads (keep some 'serialize' threads running looking for work). May be overkill :) http://ayende.com/4477/optimizing-expensive-calls#comment11http://ayende.com/4477/optimizing-expensive-calls#comment11Sat, 01 May 2010 02:09:34 GMTThere isn't any reflection involved here, just simple iteration over collections of known objects and then writing values as JSON text. I think it would be possible to improve performance here a little: under the covers the JSON is being written by a class called JsonTextWriter. Like any good public API JsonTextWriter can write to any TextWriter, checks for errors and updates some public properties with state. Since the contents of JObject et al are already guaranteed to be valid and will always output a string it could have its own internal writer which optimizes to be written to a string and fore-gos error checking and state. If performance is important that is an idea of something you could look at. I haven't done it myself because I think sub 1ms is plenty fast enough for average use already and in my opinion more important features in a serializer, but you obviously have different needs. Happy to include the source in future releases if you do write something! :) ~J http://ayende.com/4477/optimizing-expensive-calls#comment10http://ayende.com/4477/optimizing-expensive-calls#comment10Fri, 30 Apr 2010 15:58:23 GMTI was sure you had that covered but just had to check. ;) http://ayende.com/4477/optimizing-expensive-calls#comment9http://ayende.com/4477/optimizing-expensive-calls#comment9Fri, 30 Apr 2010 14:03:51 GMTJeremy, Yes, it calls that on two different objects http://ayende.com/4477/optimizing-expensive-calls#comment8http://ayende.com/4477/optimizing-expensive-calls#comment8Fri, 30 Apr 2010 13:57:43 GMTWhenever looking at the results of a profiler run, I remind myself that unnecessary calls are as important as slow calls, and often moreso once the obvious slow calls have been addressed. With that in mind, does AddDocument need to call JToken.ToString twice? http://ayende.com/4477/optimizing-expensive-calls#comment7http://ayende.com/4477/optimizing-expensive-calls#comment7Fri, 30 Apr 2010 13:55:50 GMTI mistakenly assumed that this was doing a serialization step. I'll get my coat. http://ayende.com/4477/optimizing-expensive-calls#comment6http://ayende.com/4477/optimizing-expensive-calls#comment6Fri, 30 Apr 2010 13:50:38 GMTMarc, That might be nice, but the reason issue here is that we have a Json document being saved into a file, nothing else. There isn't really a place for IL gen here. It isn't an object to json http://ayende.com/4477/optimizing-expensive-calls#comment5http://ayende.com/4477/optimizing-expensive-calls#comment5Fri, 30 Apr 2010 11:54:37 GMTI'm a strong believer in 'selectively' optimizing where it makes sense. I actually think *it does* make sense to aggressively optimize serialization as it is ultimately used on every request so every optimization you can make improves the entire performance of your application as a whole. Personally I think application performance / perceived performance is *the primary goal* of all successful internet software companies. For a good example of an optimized HTML5 site view the source and traffic of yahoo's new search page (see: inline images :): [http://search.yahoo.com/](http://search.yahoo.com/) Speed is the main reason why I'm not using JSON serialization for serializing POCO's. I don't think there is anything inherently wrong with the format, I just haven't found a JSON library with good performance. 0.8ms seconds doesn't seem like here much so maybe its not worth it for this case but bigger datasets mean longer times and I'm used to having entire web service requests finish in > 1ms. Using the Northwind dataset, I've benchmarked all leading serialization routines I could find in .NET here: [www.servicestack.net/.../...-times.2010-02-06.html](http://www.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.1000000-times.2010-02-06.html) @Marc Gravell's protobuf-net binary serialization is the clear leader here (makes every other binary serializer redundant) while I do ok with the leading text-serializer. >>I do wonder, though, if I should try a second project to take my existing IL-generator and change the leaf-nodes to handle xml / json / something else. Could be interesting ;-p Yes please do! I don't think you should worry about XML as MS's implementation is actually pretty good, and well if you use XML you're going to be more concerned with interoperability than performance. But there is a big potential for perf gains in the JSON-space - all .NET ajax apps thank you in advance for your efforts :) http://ayende.com/4477/optimizing-expensive-calls#comment4http://ayende.com/4477/optimizing-expensive-calls#comment4Fri, 30 Apr 2010 11:50:34 GMTFair enough. That won't help at all, then ;-p (feel free to delete the comment if you want to avoid any unhelpful distraction) I do wonder, though, if I should try a second project to take my existing IL-generator and change the leaf-nodes to handle xml / json / something else. Could be interesting ;-p http://ayende.com/4477/optimizing-expensive-calls#comment3http://ayende.com/4477/optimizing-expensive-calls#comment3Fri, 30 Apr 2010 10:24:57 GMTMarc :-) The data is any arbitrary JSON document. http://ayende.com/4477/optimizing-expensive-calls#comment2http://ayende.com/4477/optimizing-expensive-calls#comment2Fri, 30 Apr 2010 10:20:49 GMTHow complex is the data? If you *do* care about this, I'm pretty confident I could get you some noticeable performance increase without any change to your object model, using the (not fully released, but pretty stable) protobuf-net "v2" build. In particular, this: - has a metadata abstraction layer, so you don't need to decorate your model with attributes if you want to keep it unaware of serialization - has full ILGenerator pre-compilation (even to a dll if you really want) for performance (and of course the usual protobuf advantages of not needing to do as much UTF encoding or string matching) I've got some examples where I have to do large loops, because the measurement is in the low micro-seconds. http://ayende.com/4477/optimizing-expensive-calls#comment1http://ayende.com/4477/optimizing-expensive-calls#comment1Fri, 30 Apr 2010 10:14:30 GMT