WP7Contrib: Why we use SilverlightSerializer instead of DataContractSerializer

Like all applications developed for WP7 devices we (WP7Contrib) want to get the best performance possible from any libraries or patterns we use and this applies to how we serialize and deserialize data inside the WP7Contrib. In several of the libraries which make up the WP7Contrib we require binary serialization support, specifically we use binary serialization for the isolated storage cache provider and the storage service in the services project.

Simply after testing we found SilverightSerializer gave better performance, shown below the results of serializing a collection of 1000 items compared to the DataContractSerializer.

It shows the tick count, the equivalent time in milliseconds and the size of the generated byte array . So you can see the SilverlightSerializer gives better performance from both a time and size perspective. These results were generated using the StopWatch class.

The only downside I can see from using the SilverlightSerializer is the support for generic types used with custom collection types - you have to explicitly implement a serialization helper class for each type, you'll see this in the test application I created I had to create a class ProductCollectionSerializer to support serialization of the type ObservableCollection.

The test application 'SerializationPerformance' is available in the Spikes directory of the WP7Contrib code base.

That's it for now, I'll be back with the post about RESTful communication in WP7Contrib.