這篇文章給大家分享的是有關(guān)XML處理方法VTD-XML的示例分析的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。

長(zhǎng)壽網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站設(shè)計(jì)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營(yíng)維護(hù)。成都創(chuàng)新互聯(lián)于2013年開始到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。

問題

通常當(dāng)我們提起XML的使用時(shí)，最頭痛的部分便是XML的verbosity與XML的解析速度，當(dāng)需要處理大XML文件時(shí)這個(gè)問題便變得格外嚴(yán)重。我在這里提及的，便是如何優(yōu)化XML處理速度的話題。

當(dāng)我們選擇處理XML文件的時(shí)候，我們大致上有兩種選擇：

DOM，這是W3C的標(biāo)準(zhǔn)模型，它將XML的結(jié)構(gòu)信息以樹形的方式構(gòu)建，提供了遍歷這顆樹的接口與方法。
SAX，一種低級(jí)的parser，逐元素的向前只讀處理，不含有結(jié)構(gòu)信息。
以上兩種選擇都各有利弊，但是都不是特別好的解決方案，它們的優(yōu)缺點(diǎn)如下：

DOM

優(yōu)點(diǎn)：易用性強(qiáng)，因?yàn)樗械腦ML結(jié)構(gòu)信息都存在于內(nèi)存中，并且遍歷簡(jiǎn)單，支持XPath。
缺點(diǎn)：Parsing速度太慢，內(nèi)存占用過高（原文件的5x~10x），對(duì)于大文件來說幾乎不可能使用。
SAX

優(yōu)點(diǎn)：Parsing速度快，內(nèi)存占用不與XML的大小相聯(lián)系（可以做到XML漲內(nèi)存不漲）。
缺點(diǎn)：易用性差，因?yàn)闆]有結(jié)構(gòu)信息，并且無法遍歷，不支持XPath。如果需要結(jié)構(gòu)的話只能讀一點(diǎn)構(gòu)造一點(diǎn)，這樣的可維護(hù)性特別的差。
我們可以看出，基本上DOM與SAX是正好相反的兩個(gè)極端，但是任何一個(gè)都不能很好的滿足我們的大部分要求，我們需要找出另外一種處理方法來。注意XML的效率問題并不是XML本身的問題，而是處理XML的Parser的問題，就像我們?cè)谏厦婵吹降膬煞N方法有不同的效率權(quán)衡一樣。

思考

我們很喜歡類似DOM的使用方法，因?yàn)槲覀兛梢员闅v，這意味著可以支持XPath，大大增強(qiáng)了易用性，但是DOM的效率很低。就像我們已經(jīng)知道，效率問題出在處理機(jī)制上。那么，DOM到底有哪些方面影響了它的效率呢？下面讓我們來做一個(gè)全面的解剖：

在當(dāng)今大多數(shù)基于虛擬機(jī)（托管，或任何類似機(jī)制）技術(shù)的平臺(tái)下，對(duì)象的創(chuàng)建銷毀是一個(gè)耗時(shí)的作業(yè)（這里值得主要是Garbage Collection的耗時(shí)），DOM機(jī)制中所運(yùn)用的大量的對(duì)象創(chuàng)建銷毀無疑是影響其效率的原因之一（會(huì)引發(fā)過多的Garbage Collection）。
每個(gè)對(duì)象都會(huì)額外有32bits用來存儲(chǔ)它的內(nèi)存地址，當(dāng)像DOM一樣擁有大量對(duì)象的時(shí)候這個(gè)額外開支也是不小的。
引起以上兩個(gè)問題的最主要的效率問題在于，DOM與SAX都是extractive parsing模式，這種解析模式注定了DOM與SAX都需要大量的創(chuàng)建（銷毀）對(duì)象，引起效率問題。所謂的extractive parsing就是說在解析XML時(shí)，DOM或SAX會(huì)提取一部分原文件（一般來說是一個(gè)字符串），然后在內(nèi)存中進(jìn)行解析構(gòu)建（輸出自然就是一個(gè)或一些對(duì)象了）。拿DOM這個(gè)例子來說，DOM會(huì)將每一個(gè)element, attribute, PRocessing-instruction, comment等等都解析成對(duì)象并給與結(jié)構(gòu)，這就是所謂的extractive parsing。
由extractive的問題帶來的另一個(gè)問題便是更新效率，在DOM中（SAX因?yàn)椴恢С指滤愿静惶崴?，每一次需要做改?dòng)時(shí)，我們要做的就是將對(duì)象的信息再解析回XML的字符串，注意這個(gè)解析是個(gè)完整的解析，也就是說，原文件并沒有被利用，而是直接將DOM模型重新完整解析成XML字符串。換句話講，也就是DOM并不支持Incremental Update（增量更新）。
另一個(gè)很可能不被注意到的“小”問題便是XML的編碼，無論是何種解析方法都需要能夠處理XML的編碼，也就是說，在讀取的時(shí)候解碼，在寫入的時(shí)候編碼。DOM的另一個(gè)效率問題便是當(dāng)我對(duì)于一個(gè)大XML只想做很小的一塊兒修改的時(shí)候它也必須首先將整個(gè)文件進(jìn)行解碼，然后構(gòu)建結(jié)構(gòu)。無形中又是一個(gè)開銷。
讓我們來總結(jié)一下問題，簡(jiǎn)單的講DOM的效率問題主要出在它的extractive parsing模式上（SAX也是一樣，有同樣的問題），由此引發(fā)了一系列相關(guān)問題，如果可以擊破這些效率瓶頸的話那么可以想象XML的處理效率將進(jìn)一步的得到提高。如果XML的易用性與處理效率得到飛躍性的提高的話，那么XML的應(yīng)用范圍，應(yīng)用模式將得到更一步的升華，或許由此可以產(chǎn)生出許許多多精彩的以前連想都沒有想過的基于XML的產(chǎn)品來。

出路

VTD-XML便是對(duì)以上問題的思考后給出的答案，它是一個(gè)non-extractive XML parser，由于它出色的機(jī)制，很好的解決（避免）了上面所提出的各種問題，并且還“順便”帶來了non-extractive的其他好處，像快速的解析與遍歷、XPath的支持、Incremental Update等等。我這里有一組數(shù)據(jù)，取自于VTD-XML的官方網(wǎng)站：

VTD-XML的解析速度是SAX（with NULL content handler）的1.5x~2.0x。With NULL content handler的意思就是說SAX解析中沒有插入任何額外的處理邏輯，也就是SAX的最高速度。
VTD-XML的內(nèi)存占用是原XML的1.3x~1.5x（其中1.0x的部分是原XML，0.3x~0.5x是VTD-XML占用的部分），而DOM的內(nèi)存占用則是原XML的5x~10x。舉一個(gè)例子，如果一個(gè)XML的大小是50MB，那么用VTD-XML讀取進(jìn)來內(nèi)存占用會(huì)在65MB~75MB之間，而DOM的內(nèi)存占用則會(huì)在250M~500MB之間?；谶@個(gè)數(shù)據(jù)用DOM處理大的XML文件幾乎是不可能的選擇。
你可能會(huì)覺得不可思議，真的可以做出比DOM易用性還好，比SAX還快的XML解析器嗎？別急著下定論，還是來看看VTD-XML的原理吧！

基本原理

就像大多數(shù)好的產(chǎn)品一樣，VTD-XML的原理并不復(fù)雜，而是很巧妙。為了實(shí)現(xiàn)non-extractive這個(gè)目的，它將原XML文件原封不動(dòng)的以二進(jìn)制的方式讀進(jìn)內(nèi)存，連解碼都不做，然后在這個(gè)byte數(shù)組上解析每個(gè)element的位置并把一些信息記錄下來，之后的遍歷操作便在這些保存下來的record上進(jìn)行，如果需要提取XML內(nèi)容就利用record中的位置等信息在原始byte數(shù)組上進(jìn)行解碼并返回字符串。這一切看起來都很簡(jiǎn)單，但是，這個(gè)簡(jiǎn)單的過程確有多個(gè)性能細(xì)節(jié)在里邊，并且隱藏了若干個(gè)潛在的能力。下面我們首先來描述一下各個(gè)性能細(xì)節(jié)：

為了避免過多的對(duì)象創(chuàng)建，VTD-XML決定采用原始的數(shù)值類型作為record的類型，這樣就可以不必用heap。VTD-XML的record機(jī)制就叫做VTD（Virtual Token Descriptor），VTD將性能瓶頸在tokenization階段就解決掉了真的是很巧妙很用心的做法。VTD是一個(gè)64bits長(zhǎng)度的數(shù)值類型，記錄了每個(gè)element的起始位置（offset），長(zhǎng)度（length），深度（depth）以及token的類型（type）等信息。
注意VTD是固定長(zhǎng)度的（官方?jīng)Q定用64bits），這樣做的目的就是為了提高性能，因?yàn)殚L(zhǎng)度固定，在讀取，查詢等操作的時(shí)候格外的高效（O(1)），也就是可以用數(shù)組這種高效的結(jié)構(gòu)來組織VTD大大減少了因?yàn)榇罅渴褂脤?duì)象而產(chǎn)生的性能問題。
VTD的超能力（一點(diǎn)都不夸張地說）就在于它能夠?qū)ML這種樹形的數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單的變換成對(duì)一個(gè)byte數(shù)組的操作，任何你能想象到的對(duì)于byte數(shù)組的操作都可以應(yīng)用在XML上了。這是因?yàn)樽x取進(jìn)來的XML是二進(jìn)制的（byte數(shù)組），而VTD則記錄了每個(gè)element的位置等訪問用信息，當(dāng)我們找到要操作的VTD的時(shí)候，只要用offset與length等信息就可以對(duì)原始byte數(shù)組進(jìn)行任何操作，或者可以直接對(duì)VTD進(jìn)行操作。舉例來說，我想在一個(gè)大XML中找出一個(gè)element并刪除它，那么我只需要找到這個(gè)element的VTD（遍歷方法稍候再講），將這個(gè)VTD從VTD數(shù)組中刪除，然后再利用所有的VTD寫出到另一個(gè)byte數(shù)組中就可以了，因?yàn)閯h除的VTD標(biāo)明了要?jiǎng)h除的element的位置，所以在新寫入的byte數(shù)組中就不會(huì)出現(xiàn)這段element了，用VTD寫入新的byte數(shù)組實(shí)際上就是一個(gè)byte數(shù)組的拷貝，其效率相當(dāng)?shù)母?，這就是所謂的增量更新（incremental update）。
關(guān)于VTD-XML的遍歷方式，它采用了LC (Location Cache)，簡(jiǎn)單地說就是將VTD以其深度作為標(biāo)準(zhǔn)構(gòu)建的一個(gè)樹形的表結(jié)構(gòu)。LC的entry也是64bits長(zhǎng)的數(shù)值類型，前32bits代表一個(gè)VTD的索引（index），后32bits代表了這個(gè)VTD的第一個(gè)child的索引。利用這些信息就可以計(jì)算出任何一個(gè)你想要到達(dá)的位置了，關(guān)于具體的遍歷方法請(qǐng)參看官方網(wǎng)站的文章?；谶@種遍歷方式的VTD-XML有與DOM不同的操作接口，這是可以理解的，并且，VTD-XML的這種遍歷方式可以在最少的幾步內(nèi)將你帶到你所需要的地方去，遍歷的性能十分突出。

感謝各位的閱讀！關(guān)于“XML處理方法VTD-XML的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！

標(biāo)題名稱：XML處理方法VTD-XML的示例分析-創(chuàng)新互聯(lián)
分享地址：http://chinadenli.net/article30/deegso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、營(yíng)銷型網(wǎng)站建設(shè)、做網(wǎng)站、網(wǎng)站制作、網(wǎng)站建設(shè)、ChatGPT

廣告

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