JSON serialization performance issue on WP7

Question

I have a .JSON file which is approx. 1.5MB in size containing around 1500 JSON objects that I want to convert into domain objects at the start-up of my app.

Currently my process on the Phone (not on my development PC) takes around 23 seconds which is far too slow for me and is forcing me to write the list of objects into ApplicationSettings so that I dont have to do it each time the app loads (just first off), but even that takes 15-odd seconds to write to, and 16 seconds to read from, all of which is not really good enough.

I have not had a lot of serialization experience and I dont really know the fastest way to get it done.

Currently, I am using the System.Runtime.Serialization namespace with DataContract and DataMember approach.

Any ideas on performance with this type of data loading?

Answer 1

I found the Json.NET library to be more performant and to have better options that the standard json serializer.

One performance issue I encountered in my app was that my domain objects implemented INotifyPropertyChanged with code to support dispatching the event back to the UI thread. Since the deserialization code populated those properties I was doing a lot of thread marshalling that didn't need to be there. Cutting out the notifications during deserialization substantially increased performance.

Update: I was using Caliburn Micro which has a property on PropertyChangedBase that can turn off property changed notifications. I then added the following:

[OnDeserializing]
public void OnDeserializing(StreamingContext context)
{
    IsNotifying = false;
}

[OnDeserialized]
public void OnDeserialized(StreamingContext context)
{
    IsNotifying = true;
}

Answer 2

Try profiling your app with the free EQATEC Profiler for WP7. The real issue could be something completely unexpected and easy to fix, like the INotifyPropertyChanged-example Nigel mentions.

Answer 3

You can quickly shoot yourself in the foot using the application settings. The issue is that these are always serialized/deserialized "in bulk" and loaded in memory, so unless your objects are extremely small this can cause memory and performance issues down the road.

I am still wondering about the need for 1500 objects. Do you really need 1500 of the entire object, and if so, why - ultimately the phone is showing something to the user and no user can process 1500 bits of information at once. They can only process information that is presented, no? So is there possible parts of the object that you can show, and wait to load the other parts until later? For example, if I have 2000 contacts I will never load 2000 contacts. I might load 2000 names, let the user filter/sort names, and then when they select a name load the contact.

I would suggest serializing this to isolated storage as a file. The built-in JSON serializer has the smallest footprint on disk and performs quite well.

Answer 4

Here is a post about serialization. Use binary or Json.Net.

Answer 5

Storing/restoring into ApplicationSettings is going to involve serialization as well (pretty sure it's Xml) so I don't think you are ever going to get any faster than the 16 seconds you are seeing.

Moving that amount of data around is just not going to be fast no matter how good the deerializer. My recommendation would be to look at why you are storing that many objects. If you can't reduce the set of objects you need to store look at breaking them up into logical groups so that you can load on demand rather than up front.

Answer 6

您是否尝试过使用多个较小的文件并[并]并行序列化以查看是否会更快？