One day, I received an e-mail from a customer complaining that there was 100% CPU occupancy on our program, EDC (Engineering Data Collection) service, while handling certain XPath queries. Well, that specific XPath was really a bit complicated as you can see:

//CDResults[../../../TargetName/@Value=//SiteInformation[TargetName/@Value!=//SiteInformation[1]/TargetName/@Value and TargetName/@Value!=//SiteInformation[TargetName/@Value!=//SiteInformation[1]/TargetName/@Value][1]/TargetName/@Value][1]/TargetName/@Value]/BottomCD/@Value

I decided to do some tests on the program and some other alternative solutions. I set two goals for this test:

1. To verify if the XML parser is the part causing 100% CPU usage.
2. If so, to try to find alternative solutions for better performance.

Methodology
A test program was built to implement four different solutions but achieve the same functionality, which was to retrieve the value of a given XML based on a certain XPath query. The four solutions included the current implementation in the EDC service and three alternatives. The major difference among these four solutions was:

• Solution 1: Implements XmlDocument and XPathNavigator.Evaluate
  This was the current implementation in EDC service.
• Solution 2: Implements XPathDocument and XPathNavigator.Evaluate
• Solution 3: Implements XPathDocument and XPathNavigator.Select
• Solution 4: Implements XmlDocument.Select

Timestamps were recorded at the beginning and end of each solution. Then, the time span for each solution was calculated. All this information was stored in a log file. A CPU usage history graph was captured to illustrate the difference between the solutions. Data analysis and extra study and research was conducted after each test was done and the data become available.

Test Environment

• Desktop Computer: Dell OptiPlex GX270
• CPU: Intel Pentium 4 / 2.8GHz
• RAM: 1G
• Windows 2000 Professional v5.00.2195
• Service Pack 4 Build 2195
• .NET framework 1.1 v1.1.4322 SP1
• Visual Studio 2003 v7.1.6030

Raw Data
The source code can be downloaded from here.

• XML file: see VeritySEM_WAFER_REPORT_5.xml
• XPath query string:

//CDResults[../../../TargetName/@Value=//SiteInformation[TargetName/@Value!=//SiteInformation[1]/TargetName/@Value and TargetName/@Value!=//SiteInformation[TargetName/@Value!=//SiteInformation[1]/TargetName/@Value][1]/TargetName/@Value][1]/TargetName/@Value]/BottomCD/@Value

• Dummy Large XML: see testBigXML.zip

Test Result and Analysis
CPU Usage
The CPU occupancy rose to 100% immediately after the test application started. It could confirm that the 100%-CPU-usage issue is caused by the XML parser (see Figure 1).

Result of Each Solution
All four solutions ran correctly and got the same result: 9.161745E-02. So all the solutions are workable.

All four solutions mean 100% CPU usage, but a dramatically different time to finish. I ran the test program twice. Table 1 illustrates the time used for each solution during the two runs.

1. Time format is HH:MM:SS
2. First run ran under Visual Studio debug mode
3. Second run ran after the program was compiled as a standalone executable.