Performance, Performance, Performance - 2 - Xml Classes

Xml is very useful.  It is a convenient way to structure information in a predictable way.  It does however have its limitations and it is critical that we understand what they are.  In this blog I am going to focus on some of the Xml classes provided in the .NET Framework and their performance implications.

XmlSerializer

Frankly, this class is a pig, performance-wise.  Both logging providers use this class to serialize (and deserialize) the log.  During my profiling tests the AddLog method (called in App_Start to log the Application Start event) was always one of the top 10 slowest performing methods.

Initially I put this down to the fact that there was a Database call to add the log entry to the database, but on closer inspection I discovered that the serialization of the log properties was taking anywhere from 1-2 secs (longer than the db call).

Xml Serialization works by using reflection on the class to determine the what (and how) to serialize (convert to xml elements or attributes).  The developer informs the XmlSerializer on how to serialize the class by adding Attributes to the Class declaration and properties.  Note that in the first sentence of this paragraph I used that word "reflection".  In my previous blog I mentioned this is expensive, and in XmlSerialization this is very much the case.

This is another case of using a "generic" convenience class, without thinking about the performance implications.  I rewrote the Serialization of the Log to use a class specific serializer/deserializer using the XmlReader/XmlWriter classes and in doing so reduced the serialization cost to less than 50ms (a 20x performance gain).  Admittedly this took a few hours to write (mainly as I had never used XmlReader and XmlWriter before), compared with about 10-20 mins to write using the XmlSerializer, but the performance gain is worth it, as the log is used frequently.

We also use this class to deserialize the FriendlyUrl config file, so I rewrote that function as well (for a gain of another few hundred milliseconds on App_Start). 

A bigger project is that we also use XmlSerializer to Import/Export templates.  This will be a much larger undertaking to fix, and will also have less impact on performance as we do not Import or Export templates on every request.  So this is probably one scenario where the programming convenience outweighs the performance gains.

XmlDocument vs XPathDocument

If you are reading from an xml file there are two classes that you could use.  These are quite similar classes, as both provide access to the Xml's DOM.  However, if you are only reading (and never writing) then you should always use XPathDocument - as it is read-only and optimised for speed.

However, no matter which class you use to read the Xml Document, if you need to repetetively access nodes in the document, you should consider reading the document into a rich object model once, as the XPath queries used in SelectNode statements are expensive.

For example, one of the most expensive methods for every request is ClientAPI.BrowserSupportsFunctionality.  It is expensive because it is called so often (500-1000 times a page), but it is also expensive because each call requires two XmlDocument.SelectNode method calls.

The ClientAPI uses an xml config file to determine what capabilities a browser supports.  The xml file is loaded into an XmlDocument and cached (to save the expensive LoadXml call).  Then for each test for a browser capability the XmlDocument is fetched from the cache and parsed to determine the result.

I modified the ClientAPI so that the config file is loaded from the xml file and parsed once (using an XPathDocument) into a rich object model.  This rich object model is then cached, so that resulting calls for a browser's capabilities just query the structure (no more expensive XmlDocument.SelectNode statements)

This resulted in a reduction in cost for the ClientAPI.BrowserSupportsFunctionality from ~900ms to ~ 35ms (or about a 25x performance increase).

What is the lesson from this discussion?

It is obvious from the discussion in this Blog (together with my discussion in the previous blog on the CBO class), that as developers we need to think carefully before using what appear at first glance to be convenient classes or methods that reduce our development time. 

We need to evaluate if this code-path is going to be used on a frequent basis or only rarely.  If the code-path is going to be used frequently we need to use the most performant code, while if it is only used rarely than we can look at code that might be quicker and easier to write.

As is always the case in the real world - everything costs - and in this case convenience usually costs in performance.