XML數(shù)據(jù)讀取方式性能比較案例-創(chuàng)新互聯(lián)

這篇文章主要介紹XML數(shù)據(jù)讀取方式性能比較案例，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

邛崍網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,邛崍網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為邛崍成百上千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個(gè)售后服務(wù)好的邛崍做網(wǎng)站的公司定做！

平時(shí)我們未必要用到XML源的全部數(shù)據(jù)，所以我實(shí)驗(yàn)了一下讀取部分?jǐn)?shù)據(jù)的情況，比如根據(jù)標(biāo)題的開頭字母，出現(xiàn)位置進(jìn)行篩選。

　　對于三種隨機(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 針對XPath用戶的LINQ To XML，一刻鐘功夫你就能掌握其中奧秘。

　　但對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è)有上萬行代碼超級類，封裝了大量直接對Xml字符級進(jìn)行的操作。由于操作很接近底層，宏觀上很難找到太好的代碼優(yōu)化方式。如果篩選條件，也就是業(yè)務(wù)邏輯再復(fù)雜一點(diǎn)，代碼就會面目全非，可理解性可維護(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í)體對象創(chuàng)建的開銷。比較蹊蹺的是Linq方式，居然沒有變化，落在了最后。

　　可以測試不同的查詢條件，能看出這四種方式各有其性能極限，與Xml源的大小有關(guān)。比如對于前兩種方式，就取決于XmlDocument.Load方法執(zhí)行時(shí)間，在我本機(jī)上，Load這個(gè)Xml就需要23ms。Linq方式也不是雷打不動(dòng)，如果處理的結(jié)果很少，執(zhí)行時(shí)間會降1～2毫秒。

　　Document和Navigator方式，性能會隨數(shù)據(jù)量增大而明顯下降。很容易猜到，是因?yàn)樗鼈儎?chuàng)建了許多無用對象的緣故?？匆幌赂鞣绞絻?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，它對變化準(zhǔn)備不足，容易出錯(cuò)。更加強(qiáng)烈推薦使用Linq方式，雖然某些情況下時(shí)間性能略低于Navigator方式，但優(yōu)異的內(nèi)存占用表現(xiàn)，奠定了它的選地位。而且我相信，未來的Linq To XML，還會更加強(qiáng)大。

以上是XML數(shù)據(jù)讀取方式性能比較案例的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

新聞標(biāo)題：XML數(shù)據(jù)讀取方式性能比較案例-創(chuàng)新互聯(lián)
標(biāo)題路徑：http://www.muchs.cn/article44/dssdhe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設(shè)計(jì)公司、域名注冊、Google、網(wǎng)站設(shè)計(jì)公司、定制開發(fā)、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)

微信小程序開發(fā)