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

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

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

---

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

---

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

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

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

TinyXML主要接口類     RapidXML的主要接口類

TinyXML主要接口類	RapidXML的主要接口類
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è)具體的例子來體驗(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)類似功能的代碼：

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();
}

---

前兩天有朋友問，我的SlimXml有沒有和RapidXml對比過效率？我是第一次聽說這個(gè)庫，更不用說對比效率了，于是上他們網(wǎng)站看了下。

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

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

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

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

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

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

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

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

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

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

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

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

---