Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

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.


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.


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (269)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?