Archived CMarkup Performance Tests

Update November 20, 2010: See new XML parser performance results in CMarkup XML Parser Performance.

Release 7.0 Tests, July 17, 2004

There is a 25% jump in performance from 6.6 to 7.0 due to the new node parsing function. The improvement on large documents from 6.5 to 6.6 was due to the new segmented index array introduced in release 6.6.

Also note that the string reference version of SetDoc available in 7.0 is a significant benefit because it eliminates underlying string length and memory copy calls that transfer the zero-terminated string argument into a new string object instance.

Times are in milliseconds (i.e. 1000 = 1 second) based on release build (debug builds are slower). The lower the number, the faster the parse. Numbers are not precise, they are just samples subject to variations in CPU usage.

Machine 1: Windows 2000, 500MHz
246KB sample document with 6,343 elements
Release MFC UNICODE STL MSXML*
7.0/string ref 23 38 25 -
7.0 28 46 26 121
6.6 39 52 39 122
6.5 39 61 43 120
6.3 41 52 40 160

Machine 1: Windows 2000, 500MHz
3.81MB sample document with 100,678 elements
Release MFC UNICODE STL MSXML*
7.0/string ref 376 617 411 -
7.0 476 721 481 2047
6.6 636 806 721 2433
6.5 676 1041 741 2058
6.3 681 874 740 2579

* CMarkupMSXML with MSXML 4 was used except in the following cases where MSXML 1.0 was used: in release 6.3 MSXML4 was not implemented; in release 6.6 on 3.81MB document MSXML 3 and 4 generated stack overflow in loadXML with non-BSTR (note SetDoc work-around in release 7.0).

Release 6.3 Tests, April 2, 2002

These sample parser times are for the test project compiled in release mode; debug mode is slower. A measurement on the same 400MHz NT 4.0 box as in the article one year ago shows about double the performance due to string comparison and iteration improvements in release 6.2 and 6.3.

Times are in milliseconds (i.e. 1000 = 1 second).

Machine 1: NT 4.0, 400MHz
Parse MFC UNICODE STL MSXML
246KB 47 63 47 156
3.81MB 828 1031 891 2390

Release 5.3 Tests, April 4, 2001

Parser performance data has been gathered using the millisecond count displayed in the status bar. Here are some example times using release 5.3 of CMarkup, CMarkupSTL, and CMarkupMSXML. The times for CMarkupMSXML represent the underlying speed of MSXML (msxml.dll versions are 2.0a 3/18/99 on machine 1 and 2.5 12/7/99 on machine 2) plus BSTR conversion.

Times are in milliseconds (i.e. 1000 = 1 second).

Machine 1: NT 4.0, 400MHz
Parse Plain Unicode STL MSXML
246KB 94 94 110 140
3.81MB 1515 1656 1875 2375

Machine 2: Windows 2000, 733MHz
Parse Plain Unicode STL MSXML
246KB 54 50 60 90
4.89MB 1404 1201 1462 1912

Machine 3: Windows 95, 166MHz
Parse Plain STL
246KB 256 298

CMarkup parses fast primarily because it only takes one pass; see CMarkup Indexing Explained and Inside the CMarkup Parser.

 

comment posted CMarkup vs CMarkupMSXML

Muneer 03-Apr-2006

which is faster in performance 1. CMarkup 2. CMarkupMSXML?

For raw parsing, CMarkup is 4 times faster than CMarkupMSXML in the latest examples above. The speed of CMarkupMSXML represents the speed of the underlying MSXML. MSXML does complete well-formedness checking, but probably the chief reason for CMarkup's speed advantage is that CMarkup maintains a separate index rather than breaking up the document into objects. Note that there are other ways of measuring performance such as with modifying and creating documents, not shown here. With certain types of modification, especially with intensive use of attributes (that change length), CMarkup is not spectacular. But CMarkup generally performs very well because of its light weight approach.

 

comment posted Performance gain in 9.0?

Bernd 13-Jun-2007

We are currently using CMarkup 8.0. Do you know if there is a relevant performance gain with version 9.0 against 8.0. I saw the performance tests on your web site, but they stop with version 7.0.

I have not done any tests since 7.0, except to ensure that there were not any obvious performance changes. The performance of 9.0 should be equal to 8.0 (and 7.0). If you do not need new features, I do not see any reason to upgrade to 9.0 unless you are affected by any of the bug fixes detailed in the release notes.