• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            近來找到一個快速的xml庫,試用了一下,方法和現在使用的tinyxml差不多,很容易上手,如果有機會可以移植到項目里面試試

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

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



            rapidxml是一個快速的xml庫,官方網站: http://rapidxml.sourceforge.net/,根據manual看到,他竟然比tinyxml快了50-100倍


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

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

            其次它的設計非常的簡潔,只依賴于標準庫中的幾個基本的類。它的輸入輸出都是字符串,這樣很好,一個庫就應該關注自己核心的內容,做盡量少的事情。它的API其實和TinyXML倒是有幾分相似,用過TinyXML的人應該很容易上手:

            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

            下面還是看一個具體的例子來體驗一下,下面是TinyXML官方教程中創建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實現類似功能的代碼:

            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對比過效率?我是第一次聽說這個庫,更不用說對比效率了,于是上他們網站看了下。

            好家伙,居然號稱比TinyXml快30~60倍,而且是Boost.PropertyTree的默認xml解析器。

            于是有點好奇,因為以前也沒有特別關心過SlimXml的效率。

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

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

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

            要說明的是,RapidXml的這個parse是一個模板函數,必須給一個flag的參數,我測試的時候給的是默認的0

            測試結果,解析這個3.3萬行,1.5M大小的xml,三個庫分別花了

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

            結論是,RapidXml果然很強悍,居然比我的SlimXml快5倍多。但是并沒有如作者所說比TinyXml快30~60倍,只有不到15倍。據說對比用的是一個約50k大小的xml文件,可惜并沒有提供下載,不然可以驗證一下。

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

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

            我估計RapidXml速度快的主要原因是對memory pool的使用,畢竟在解析過程中需要創建大量的string,可以想象用memory pool和直接走默認的new很容易產生超過一個數量級的效率差異。









            posted on 2010-11-15 17:24 大寶天天見 閱讀(4416) 評論(1)  編輯 收藏 引用 所屬分類: 6.Lua/XML

            評論:
            # re: [摘錄]rapidxml,一個快速的xml庫[未登錄] 2010-11-22 12:15 | 微妙的平衡
            RapidXml 基本沒有new過數據,而是直接在XML內容的內存中對其進行修改。例如將節點的<>位置作為字符串\0結尾。所有node的節點指針都是指向了原始XML內存的位置。  回復  更多評論
              
            国产精品熟女福利久久AV| 精品人妻伦九区久久AAA片69| 久久精品国产亚洲AV电影 | 国产亚州精品女人久久久久久| 精品免费久久久久久久| 久久777国产线看观看精品| 久久91这里精品国产2020| 国产偷久久久精品专区| 国产国产成人久久精品| 精品久久久久久中文字幕大豆网| 久久综合综合久久狠狠狠97色88| 亚洲综合久久久| 色综合久久精品中文字幕首页| 香蕉久久久久久狠狠色| 99久久精品免费看国产| 久久精品国产亚洲AV麻豆网站 | 亚洲а∨天堂久久精品9966| 久久综合狠狠综合久久综合88 | 亚洲精品第一综合99久久| 91精品国产9l久久久久| 亚洲国产精品高清久久久| 久久丝袜精品中文字幕| 久久精品男人影院| 久久国产欧美日韩精品| 久久狠狠爱亚洲综合影院 | 久久久久99精品成人片欧美| 亚洲国产精品无码久久青草| 国产91久久综合| 国产L精品国产亚洲区久久 | 国产精品18久久久久久vr| 亚洲精品乱码久久久久久蜜桃不卡 | 老男人久久青草av高清| 伊人久久大香线蕉精品不卡 | 久久久久亚洲av毛片大| 大香网伊人久久综合网2020| 久久99国产亚洲高清观看首页 | 亚洲综合精品香蕉久久网| 久久久久久精品无码人妻| 久久青青草视频| 久久久一本精品99久久精品88| 久久精品国产99国产精品导航|