locked
XmlSerializer performance on deserialization. RRS feed

  • Question

  • User138 posted

    I've got a case where our old code used to run seemingly a lot faster than the new code, and I wondered if my choice of using nullable fields was perhaps not the best in terms of efficiency, at least on iOS?

    Originally, I had been using a pattern like "bool Paid" and "DateTime PaidAt". But lately I moved to using something like "DateTime? PaidAt" to basically handle both properties in one. Seems efficient, but some testing recently indicates that the newer code with maybe 25% more properties is vastly slower to deserialize. It is deserializing about 1.1MB of data, which is about 500 objects. On my 4S it takes 2.5 seconds, on the 4 it takes 5 seconds. A 4S on the old code deserialized and loaded them all into a collection in 3 seconds - loading them into the collection alone on the new code takes 4 seconds but there are other reasons for that too.

    I just wondered if anyone had any insight on this? It's hard for me to test or prove because I'm looking at a class with about 80 properties, and to change the newer ones from a nullable to a pair of properties and then re-code the app to handle that just to test would be a nightmare, especially as I can't really do that or it will break existing code.

    Thursday, January 10, 2013 6:37 AM

All replies

  • User1430 posted

    Hi Dean,

    I've done a quick search on Bugzilla and was unable to find a bug logged against your issue. Although I have put together a test project which serializes a list of 500 objects with a nullable property vs 500 objects with a no nullable properties and my results are:

    173ms 500 objects with 1 nullable property. 7ms 500 objects with 0 nullable properties.

    The initial test was on my Mac using the Mono 2.10.9 runtime so I thought it would be worth checking the results on a Wintel.

    The results for running with .Net 4 on Windows 7:

    8ms 500 objects with 1 nullable property. 4ms 500 objects with 0 nullable properties.

    I think we can say that the xmlserializer class may have a bug that causes it to be approximately 20x slower than the MS version. I shall log this on Bugzilla for you, hopefully someone from Xamarin will chip in with their thoughts as well.

    Friday, January 11, 2013 2:20 PM
  • User138 posted

    Hi Michael,

    I also did some similar tests (worked out in the end that I could just add some fake calls to the service and try that).

    I created one class with 50 bool properties and 50 DateTime properties. I serialized 500 of them, and it took about 10 seconds to deserialize on the iPhone 4 - this was about 2.2MB of data.

    I created another class with 50 DateTime? properties. I serialized 500 of them, and it took about 4 seconds to deserialize - this was about 900K of data.

    Looking at that, I'm not sure if it's the data type, or just a linea factor of the size of the data becase...

    I then added 50 bool ShouldSerialize() { return false; } functions to the second class, meaning they would serialize to pretty much nothing as no property would be in the XML. I serialized 500 of those, and it was deserialized in about .1 of a second for just 20K of data.

    So in MonoTouch at least, it seems the expense is in the traversing of the XML and not just the data type?

    Friday, January 11, 2013 3:42 PM
  • User27717 posted

    Can you please link back to the bugzilla entry for the benefit of others reaching this thread?

    We are also experiencing issues with XMLSerializer. We frequently create new XmlSerializer instances, which according to http://msdn.microsoft.com/en-us/library/ff650685.aspx (search for OnApplicationStart) should be cheap after the first instantiation for a type. However this caused massive performance problems, which was quickly resolved by caching a single instance of XMLSerializer as a member variable and routing all of our calls to that.

    Not intending to hijack the thread. Please do let me know if I should post this elsewhere.

    Monday, April 14, 2014 3:17 PM