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.

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.

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.