近來(lái)找到一個(gè)快速的xml庫(kù),試用了一下,方法和現(xiàn)在使用的tinyxml差不多,很容易上手,如果有機(jī)會(huì)可以移植到項(xiàng)目里面試試

自從用了xml后對(duì)他是又愛(ài)又恨,他的確能代替配置文件,但是當(dāng)文件容量大到一定量的時(shí)候?yàn)?zāi)難就降臨了,比如讀取一個(gè)50M的xml文件,往往讀取花上10秒,解析再花上20秒,還要占用大量?jī)?nèi)存空間,十分頭痛.所以實(shí)際項(xiàng)目中都會(huì)將xml再轉(zhuǎn)為二進(jìn)制文件來(lái)處理,但是xml的靈活性的確很方便,如果rapidxml能接近二進(jìn)制的速度,當(dāng)然就太好啦,還沒(méi)有測(cè)試過(guò),下面是一些介紹.

貌似tinyxml會(huì)遇到unicode障礙,rapidxml不會(huì),如果項(xiàng)目要做多語(yǔ)言版本就必須面臨解決這個(gè)問(wèn)題...

---

rapidxml是一個(gè)快速的xml庫(kù)，官方網(wǎng)站： http://rapidxml.sourceforge.net/，根據(jù)manual看到，他竟然比tinyxml快了50-100倍

---

目前我公司開(kāi)發(fā)的Nexus Engine的底層對(duì)象序列化使用了TinyXML來(lái)讀寫(xiě)XML文件。TinyXML有兩個(gè)不爽的地方，一是它的接口使用FILE*，另外一個(gè)是它對(duì) wchar_t不能很好的支持。前陣子看Boost庫(kù)的更新中多了一個(gè)PropertyTree，他在處理XML時(shí)用到了另外一個(gè)小的庫(kù) –RapidXML。既然間接的是Boost庫(kù)的一部分，所以是值得一試的。于是找到其官方網(wǎng)站（http://rapidxml.sourceforge.net/）研究了一番。一看之下，甚是滿(mǎn)意，也推薦給大家看看！

首先就是速度，據(jù)它自己宣稱(chēng)比TinyXML快30到60倍，比Xerces DOM快50到100倍！詳細(xì)的測(cè)試比較請(qǐng)見(jiàn)其用戶(hù)手冊(cè)（http://rapidxml.sourceforge.net/manual.html）的“4. Performance ”一節(jié)。

其次它的設(shè)計(jì)非常的簡(jiǎn)潔，只依賴(lài)于標(biāo)準(zhǔn)庫(kù)中的幾個(gè)基本的類(lèi)。它的輸入輸出都是字符串，這樣很好，一個(gè)庫(kù)就應(yīng)該關(guān)注自己核心的內(nèi)容，做盡量少的事情。它的API其實(shí)和TinyXML倒是有幾分相似，用過(guò)TinyXML的人應(yīng)該很容易上手：

TinyXML主要接口類(lèi)     RapidXML的主要接口類(lèi)

TinyXML主要接口類(lèi)	RapidXML的主要接口類(lèi)
class TiXmlDocument	template<class Ch = char> class xml_document
class TiXmlNode	template<class Ch = char> class xml_node
class TiXmlAttribute	template<class Ch = char> class xml_attribute

下面還是看一個(gè)具體的例子來(lái)體驗(yàn)一下，下面是TinyXML官方教程中創(chuàng)建XML文檔的一段代碼：

void build_simple_doc( )
{
// Make xml: <?xml ..><Hello>World</Hello>
TiXmlDocument doc;
TiXmlDeclaration * decl = new TiXmlDeclaration( “1.0″, “”, “” );
TiXmlElement * element = new TiXmlElement( “Hello” );
TiXmlText * text = new TiXmlText( “World” );
element->LinkEndChild( text );
doc.LinkEndChild( decl );
doc.LinkEndChild( element );
doc.SaveFile( “madeByHand.xml” );
}

下面是使用RapidXML實(shí)現(xiàn)類(lèi)似功能的代碼：

void build_simple_doc_by_rapidxml()
{
xml_document<> doc;
xml_node<>* decl = doc.allocate_node(node_declaration);
xml_attribute<>* decl_ver =
doc.allocate_attribute(“version”, “1.0″);
decl->append_attribute(decl_ver);
doc.append_node(decl);

xml_node<>* node =
doc.allocate_node(node_element,    “Hello”, “World”);
doc.append_node(node);

string text;
rapidxml::print(std::back_inserter(text), doc, 0);

// write text to file by yourself
}

下面是使用RapidXML分析XML的樣例代碼：

void parse_doc_by_rapidxml(char* xml_doc)
{
xml_document<> doc;        // character type defaults to char
doc.parse<0>(xml_doc);  // 0 means default parse flags

xml_node<> *node = doc.first_node(“Hello”);
string node_val = node->value();
}

---

前兩天有朋友問(wèn)，我的SlimXml有沒(méi)有和RapidXml對(duì)比過(guò)效率？我是第一次聽(tīng)說(shuō)這個(gè)庫(kù)，更不用說(shuō)對(duì)比效率了，于是上他們網(wǎng)站看了下。

好家伙，居然號(hào)稱(chēng)比TinyXml快30～60倍，而且是Boost.PropertyTree的默認(rèn)xml解析器。

于是有點(diǎn)好奇，因?yàn)橐郧耙矝](méi)有特別關(guān)心過(guò)SlimXml的效率。

于是分別下載了TinyXml-2.6.1和RapidXml-1.13，迅速用vc8建立了兩個(gè)測(cè)試工程，在系統(tǒng)中搜”*.xml”，找到了一個(gè)比較合適的測(cè)試文件。它足夠大（1.5M），utf-8編碼并且包含中/英文，有一定層次深度，大約3.3萬(wàn)行。測(cè)試文件可以從這里下載

測(cè)試對(duì)象是三個(gè)庫(kù)從內(nèi)存字符串解析xml的函數(shù)，這樣能排除從硬盤(pán)上讀文件這種不穩(wěn)定因素的干擾，而且RapidXml貌似只支持從內(nèi)存里解析

• slim::XmlDocument::loadFromMemory()
• TiXmlDocument::Parse()
• rapidxml::xml_document<char>::parse<flag>()

要說(shuō)明的是，RapidXml的這個(gè)parse是一個(gè)模板函數(shù)，必須給一個(gè)flag的參數(shù)，我測(cè)試的時(shí)候給的是默認(rèn)的0

測(cè)試結(jié)果，解析這個(gè)3.3萬(wàn)行，1.5M大小的xml，三個(gè)庫(kù)分別花了

• SlimXml: 22ms
• TinyXml: 54ms
• RapidXml: 4ms!

結(jié)論是，RapidXml果然很強(qiáng)悍，居然比我的SlimXml快5倍多。但是并沒(méi)有如作者所說(shuō)比TinyXml快30~60倍，只有不到15倍。據(jù)說(shuō)對(duì)比用的是一個(gè)約50k大小的xml文件，可惜并沒(méi)有提供下載，不然可以驗(yàn)證一下。

比較欣慰的是，在我并沒(méi)有很關(guān)注效率的情況下，SlimXml仍然比TinyXml快2.5倍。SlimXml走的是簡(jiǎn)單小巧路線(xiàn)，源代碼只有32k，而TinyXml和RapidXml的源碼分別是147k和141k，有這樣的效率可以滿(mǎn)意了。在我有很多空閑以前，估計(jì)我也不會(huì)再去優(yōu)化它，因?yàn)檫@個(gè)庫(kù)主要還是針對(duì)幾十上百行的小文件，解析特別大的xml不在我考慮的范圍之內(nèi)。

以下是RapidXml提供的常見(jiàn)xml庫(kù)效率對(duì)照表，其中還很牛鼻地提供了和strlen()函數(shù)的效率對(duì)比

我估計(jì)RapidXml速度快的主要原因是對(duì)memory pool的使用，畢竟在解析過(guò)程中需要?jiǎng)?chuàng)建大量的string，可以想象用memory pool和直接走默認(rèn)的new很容易產(chǎn)生超過(guò)一個(gè)數(shù)量級(jí)的效率差異。

---