Swimming in a pool of XmlSerializer

While I was looking at the data storage portion of DasBlog for improvements, a low hanging fruit hit me on the forehead: XmlSerializer.  XmlSerializer is a major feature of .NET Framework that makes it really easy to read and write data structures from and to XML.

To use XmlSerializer, all you have to do is mark some members of the data structures with .NET attributes — .NET attributes are just source code comments for programs instead of people – that provide hints like this member should be an element and the element name should be such and such.

Ease of use encourages ease of abuse.

XmlSerializer is a rather complex beast so the class takes a while to instantiate.  What hit me on the forehead was that DasBlog was using it everywhere and XmlSerializer was being instantiated substantial number of times per request: a juicy low hanging fruit indeed.

So I implemented XmlSerializerFactory which maintains a pool (as in car pool) for XmlSerializer instances and rewired DasBlog to use it whenever it needs an XmlSerializer.  There are actually multiple pools because XmlSerializer instances are target data structure specific.

All that took no more than 30 minutes but the result was very rewarding.  DasBlog with XmlSerializer pooling was noticeably faster.  My guestimate is that it's 20%-30% faster depending on the page type being accessed.  Woohoo!


It turns out that .NET 1.1 version of XmlSerializer uses an internal cache already although it depends on which constructor is used.  So the speed improvement I saw was either a hallucination or due to some other changes I made.