Newtonsoft.Json

[mvallevand]

For dll's that might have widespread use what do other dev's think is the best method of distribution? I don't expect NextPVR will be able to load different version of the dll for different plugins so common might be ok, except sub might have a future need. For the next release I need Newtonsoft.Json in SearchLite and imageGrabLite

Martin

[whurlston]

I haven't used Newtonsoft.Json since my Netflix plugin. I started using

Code:

System.Web.Script.Serialization.JavaScriptSerializer

instead. With .Net 4, I use

Code:

System.Runtime.Serialization.Json.DataContractJsonSerializer

But to answer your question, common would be a good place (until sub needs to make use of it).

[mvallevand]

Ok thanks for your feedback, I will try Common unless others balk.

I guess I opt for the extra performance. http://james.newtonking.com/archive/2013...mance.aspx

Martin

[whurlston]

For most of my usage, I would never see the gains he shows in that chart due to the small blocks of JSON data. Parsing 4 youtube pages in a row (for some tests I was doing) to get the streams, my Deserialize times on the pages are as follows:

126 ms
3 ms
5 ms
2 ms

As you can see, the first one takes the most time but subsequent ones are much, much quicker. There are also three deserializations happening per page so thats an average of about 1ms/deserialization on pages after the first. This was also running the debugger (launched from VS 2012) so there is a performance hit there as well.

Granted, if I was still working with the Netflix dataset, I would be looking at more places to increase performance.

Edit: The skewed time on the first deserialization is due to the time required to load the required assemblies for the first time.

[whurlston]

Martin, have you seen the FridayThe13th json parser? http://procbits.com/2011/08/11/fridaythe...ht-and-net

It looks pretty interesting and is supposedly faster than NewtonSoft's.

[mvallevand]

Doh, t took me a few seconds to figure out the name. Thanks, I do like the option to camelize, I'll keep it it my bag of trickes to try. The new Schedules Direct API uses JSON and it involves 1000's and 1000s of potential JSON calls.

Martin

[whurlston]

Yeah, I thought the name was pretty clever.

I'm adding it to my NExtUtility.dll (just a collection of useful functions) for now (with the intention of playing with it later) whose source will be released with the youtube plugin. I'm probably too far along with the youtube plugin to try using it on that but I might try it on some other projects I have in the works.

SD (or tv listings in general) would definitely be an area where I would be looking for area where I would be looking for all the performance I could get.

BTW: You only need the two .cs files located at https://github.com/jprichardson/FridayTh...dayThe13th -- no need to download the whole package.

[reven]

lol I had to google what the name meant, completely forgot his name was jason voorhees (I was trying to read it as FridayTheieth, thinking what the heck is that...)

[mvallevand]

BTW: You only need the two .cs files located at https://github.com/jprichardson/FridayTh...dayThe13th -- no need to download the whole package.

Ok thanks, including the source and not the binaries would make your code LGPL v2 which could be a concern.

Martin

[whurlston]

NExtUtilities is a collection of things that will be in multiple dlls. For example, NextPVR (semi-)specific functions (Onscreen keyboard popup, image processing, etc) will be in a base dll while DirectShow stuff will be in another (which will be LGPL'd). I haven't decided the license for the base dll yet but if I don't go with LGPL, I will move that to a separate dll like the DirectShow stuff.