您好,登錄后才能下訂單哦!
這篇文章主要介紹XML數(shù)據(jù)讀取方式性能比較案例,文中介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們一定要看完!
平時(shí)我們未必要用到XML源的全部數(shù)據(jù),所以我實(shí)驗(yàn)了一下讀取部分?jǐn)?shù)據(jù)的情況,比如根據(jù)標(biāo)題的開頭字母,出現(xiàn)位置進(jìn)行篩選。
對(duì)于三種隨機(jī)讀取方式來說,只要改變查詢條件即可
XmlDocument: var nodeList = doc.DocumentElement.SelectNodes("item[substring(title,1,1)='M'][position() mod 10 = 0]"); XPathNavigator: var nodeList = nav.Select("/channel/item[substring(title,1,1)='M'][position() mod 10 = 0]"); Xml Linq: var nodelist = from node in xd.XPathSelectElements("/channel/item[substring(title,1,1)='M'][position() mod 10 = 0]")
使用XPath,只要改一行代碼。XPath也相當(dāng)容易掌握,比SQL簡單得多??梢詤⒖糤3C Shcool的語法介紹以及MSDN 針對(duì)XPath用戶的LINQ To XML,一刻鐘功夫你就能掌握其中奧秘。
但對(duì)XmlReader方式,可沒那么容易了,同樣是讀title以M開頭,每十項(xiàng)取一項(xiàng),想了半天,楞是沒想出個(gè)優(yōu)雅點(diǎn)的實(shí)現(xiàn)方式,只好如此:
代碼
static List<Channel> testXmlReader2() { var lstChannel = new List<Channel>(); var reader = XmlReader.Create(xmlStream); int n = 0;Channel channel = null; Search: while (reader.Read()) { if (reader.Name == "item" && reader.NodeType == XmlNodeType.Element) { while (reader.Read()) { if (reader.Name == "item") break; if (reader.NodeType != XmlNodeType.Element) continue; switch (reader.Name) { case "title": var title = reader.ReadString(); if (title[0] != 'M') goto Search; n++; if (n % 10 != 0) goto Search; channel = new Channel(); channel.Title = title; break; case "link": channel.Link = reader.ReadString(); break; case "description": channel.Description = reader.ReadString(); break; case "content": channel.Content = reader.ReadString(); break; case "pubDate": channel.PubDate = reader.ReadString(); break; case "author": channel.Author = reader.ReadString(); break; case "category": channel.Category = reader.ReadString(); break; default: break; } lstChannel.Add(channel); } } } return lstChannel; }
可以看到,代碼結(jié)構(gòu)發(fā)生了明顯變化。為了作條件篩選,只得增加局部變量n,調(diào)整了實(shí)體類初始化,和加入集合語句的所在位置,甚至被迫用了遺忘多年的goto語句進(jìn)行跳轉(zhuǎn)(VB還好些)。業(yè)務(wù)邏輯滲進(jìn)了代碼細(xì)節(jié)的實(shí)現(xiàn),用老趙的話說就是,一陣語法噪音的氣息撲面而來。
XmlTextReader的實(shí)現(xiàn)代理類XmlTextReaderImp(internal的,不能直接用),是個(gè)有上萬行代碼超級(jí)類,封裝了大量直接對(duì)Xml字符級(jí)進(jìn)行的操作。由于操作很接近底層,宏觀上很難找到太好的代碼優(yōu)化方式。如果篩選條件,也就是業(yè)務(wù)邏輯再復(fù)雜一點(diǎn),代碼就會(huì)面目全非,可理解性可維護(hù)性如鏡花水月。
現(xiàn)在再來比較一下時(shí)間性能:
XmlDocment 26ms XPathNavigator 26ms XmlTextReader 20ms Xml Linq 28ms
四種方式數(shù)據(jù)變得接近了,Document和Navigator消耗時(shí)間大幅下降,Reader方式下降不多,因?yàn)槿匀灰獜念^Read到底,減少的3ms可以認(rèn)為由于減少了實(shí)體對(duì)象創(chuàng)建的開銷。比較蹊蹺的是Linq方式,居然沒有變化,落在了最后。
可以測試不同的查詢條件,能看出這四種方式各有其性能極限,與Xml源的大小有關(guān)。比如對(duì)于前兩種方式,就取決于XmlDocument.Load方法執(zhí)行時(shí)間,在我本機(jī)上,Load這個(gè)Xml就需要23ms。Linq方式也不是雷打不動(dòng),如果處理的結(jié)果很少,執(zhí)行時(shí)間會(huì)降1~2毫秒。
Document和Navigator方式,性能會(huì)隨數(shù)據(jù)量增大而明顯下降。很容易猜到,是因?yàn)樗鼈儎?chuàng)建了許多無用對(duì)象的緣故??匆幌赂鞣绞絻?nèi)存占用便知,在數(shù)據(jù)全部加載不篩選情況下,Document方式占用了23.3M左右的內(nèi)存,而Navigator方式只要22.9M左右,這也解釋了為什么Document方式性能下降更明顯。Reader方式數(shù)據(jù)全加載,只要20.1M左右內(nèi)存,除去程序啟動(dòng)本身的開銷,較前兩種內(nèi)存占用不到一半。Linq方式在內(nèi)存方面又有驚艷表現(xiàn),只比Reader方式多占了不到500k。
進(jìn)一步的分析,得出了進(jìn)一步的結(jié)論:除非有特別需要,慎用XmlTextReader,它對(duì)變化準(zhǔn)備不足,容易出錯(cuò)。更加強(qiáng)烈推薦使用Linq方式,雖然某些情況下時(shí)間性能略低于Navigator方式,但優(yōu)異的內(nèi)存占用表現(xiàn),奠定了它的首選地位。而且我相信,未來的Linq To XML,還會(huì)更加強(qiáng)大。
以上是XML數(shù)據(jù)讀取方式性能比較案例的所有內(nèi)容,感謝各位的閱讀!希望分享的內(nèi)容對(duì)大家有幫助,更多相關(guān)知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。