XML處理方法VTD-XML的示例分析

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

問題

通常當我們提起XML的使用時，最頭痛的部分便是XML的verbosity與XML的解析速度，當需要處理大XML文件時這個問題便變得格外嚴重。我在這里提及的，便是如何優化XML處理速度的話題。

當我們選擇處理XML文件的時候，我們大致上有兩種選擇：

DOM，這是W3C的標準模型，它將XML的結構信息以樹形的方式構建，提供了遍歷這顆樹的接口與方法。
SAX，一種低級的parser，逐元素的向前只讀處理，不含有結構信息。
以上兩種選擇都各有利弊，但是都不是特別好的解決方案，它們的優缺點如下：

DOM

優點：易用性強，因為所有的XML結構信息都存在于內存中，并且遍歷簡單，支持XPath。
缺點：Parsing速度太慢，內存占用過高（原文件的5x~10x），對于大文件來說幾乎不可能使用。
SAX

優點：Parsing速度快，內存占用不與XML的大小相聯系（可以做到XML漲內存不漲）。
缺點：易用性差，因為沒有結構信息，并且無法遍歷，不支持XPath。如果需要結構的話只能讀一點構造一點，這樣的可維護性特別的差。
我們可以看出，基本上DOM與SAX是正好相反的兩個極端，但是任何一個都不能很好的滿足我們的大部分要求，我們需要找出另外一種處理方法來。注意XML的效率問題并不是XML本身的問題，而是處理XML的Parser的問題，就像我們在上面看到的兩種方法有不同的效率權衡一樣。

思考

我們很喜歡類似DOM的使用方法，因為我們可以遍歷，這意味著可以支持XPath，大大增強了易用性，但是DOM的效率很低。就像我們已經知道，效率問題出在處理機制上。那么，DOM到底有哪些方面影響了它的效率呢？下面讓我們來做一個全面的解剖：

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

出路

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

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

基本原理

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

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

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