序言
本文所提及的VTD-XMLq本文作者原创，作者只是对它进行介l?
问题
通常当我们提起XML的用时Q最头痛的部分便是XML的verbosity与XML的解析速度Q当需要处理大XML文g时这个问题便变得格外严重。我在这里提及的Q便是如何优化XML处理速度的话题?
当我们选择处理XML文g的时候，我们大致上有两种选择Q?
DOMQ这是W3C的标准模型，它将XML的结构信息以树Ş的方式构建，提供了遍历这颗树的接口与Ҏ?
SAXQ一U低U的parserQ逐元素的向前只读处理Q不含有l构信息?br />以上两种选择都各有利弊，但是都不是特别好的解x案，它们的优~点如下Q?
DOM
优点Q易用性强Q因为所有的XMLl构信息都存在于内存中，q且遍历单，支持XPath?
~点QParsing速度太慢Q内存占用过高（原文件的5x~10xQ，对于大文件来说几乎不可能使用?br />SAX
优点QParsing速度快，内存占用不与XML的大相联系Q可以做到XML涨内存不涨）?
~点Q易用性差Q因为没有结构信息，q且无法遍历Q不支持XPath。如果需要结构的话只能读一Ҏ造一点，q样的可l护性特别的差?br />我们可以看出Q基本上DOM与SAX是正好相反的两个极端Q但是Q何一个都不能很好的满x们的大部分要求，我们需要找出另外一U处理方法来。注意XML的效率问题ƈ不是XML本n的问题，而是处理XML的Parser的问题，像我们在上面看到的两种Ҏ有不同的效率权衡一栗?/p>
思?
我们很喜Ƣ类似DOM的用方法，因ؓ我们可以遍历Q这意味着可以支持XPathQ大大增Z易用性，但是DOM的效率很低。就像我们已l知道，效率问题出在处理机制上。那么，DOM到底有哪些方面媄响了它的效率呢？下面让我们来做一个全面的解剖Q?/p>
在当今大多数Z虚拟机（托管Q或McM机制Q技术的q_下，对象的创建销毁是一个耗时的作业（q里值得主要是Garbage Collection的耗时Q，DOM机制中所q用的大量的对象创徏销毁无疑是影响其效率的原因之一Q会引发q多的Garbage CollectionQ?
每个对象都会额外?2bits用来存储它的内存地址Q当像DOM一h有大量对象的时候这个额外开支也是不的?
引v以上两个问题的最主要的效率问题在于，DOM与SAX都是extractive parsing模式Q这U解析模式注定了DOM与SAX都需要大量的创徏Q销毁）对象Q引h率问题。所谓的extractive parsing是说在解析XMLӞDOM或SAX会提取一部分原文Ӟ一般来说是一个字W串Q，然后在内存中q行解析构徏Q输然就是一个或一些对象了Q。拿DOMq个例子来说QDOM会将每一个element, attribute, processing-instruction, comment{等都解析成对象q给与结构，q就是所谓的extractive parsing?
由extractive的问题带来的另一个问题便是更新效率，在DOM中（SAX因ؓ不支持更新所以根本不提它Q，每一ơ需要做改动Ӟ我们要做的就是将对象的信息再解析回XML的字W串Q注意这个解析是个完整的解析Q也是_原文件ƈ没有被利用，而是直接DOM模型重新完整解析成XML字符丌Ӏ换句话Ԍ也就是DOMq不支持Incremental UpdateQ增量更斎ͼ?
另一个很可能不被注意到的“小”问题便是XML的编码，无论是何U解析方法都需要能够处理XML的编码，也就是说Q在d的时候解码，在写入的时候编码。DOM的另一个效率问题便是当我对于一个大XML只想做很的一块儿修改的时候它也必首先将整个文gq行解码Q然后构建结构。无形中又是一个开销?br />让我们来ȝ一下问题，单的讲DOM的效率问题主要出在它的extractive parsing模式上（SAX也是一P有同L问题Q，由此引发了一pd相关问题Q如果可以击破这些效率瓶颈的话那么可以想象XML的处理效率将q一步的得到提高。如果XML的易用性与处理效率得到飞跃性的提高的话Q那么XML的应用范_应用模式得到更一步的升华Q或许由此可以生出许许多多_ֽ的以前连想都没有惌的基于XML的品来?/p>
\
VTD-XML便是对以上问题的思考后l出的答案，它是一个non-extractive XML parserQ由于它的机Ӟ很好的解冻I避免Q了上面所提出的各U问题，q且q“顺侎쀝带来了non-extractive的其他好处，像快速的解析与遍历、XPath的支持、Incremental Update{等。我q里有一l数据，取自于VTD-XML的官方网站：
VTD-XML的解析速度是SAXQwith NULL content handlerQ的1.5x~2.0x。With NULL content handler的意思就是说SAX解析中没有插入Q何额外的处理逻辑Q也是SAX的最高速度?
VTD-XML的内存占用是原XML?.3x~1.5xQ其?.0x的部分是原XMLQ?.3x~0.5x是VTD-XML占用的部分）Q而DOM的内存占用则是原XML?x~10x。D一个例子，如果一个XML的大是50MBQ那么用VTD-XMLdq来内存占用会在65MB~75MB之间Q而DOM的内存占用则会在250M~500MB之间。基于这个数据用DOM处理大的XML文g几乎是不可能的选择?br />你可能会觉得不可思议Q真的可以做出比DOM易用性还好，比SAXq快的XML解析器吗Q别急着下定论，q是来看看VTD-XML的原理吧Q?/p>
基本原理
像大多数好的品一PVTD-XML的原理ƈ不复杂，而是很y妙。ؓ了实现non-extractiveq个目的Q它原XML文g原封不动的以二进制的方式读进内存Q连解码都不做，然后在这个byte数组上解析每个element的位|ƈ把一些信息记录下来，之后的遍历操作便在这些保存下来的record上进行，如果需要提取XML内容利用record中的位置{信息在原始byte数组上进行解码ƈq回字符丌Ӏ这一切看h都很单，但是Q这个简单的q程有多个性能l节在里边，q且隐藏了若q个潜在的能力。下面我们首先来描述一下各个性能l节Q?/p>
Z避免q多的对象创建，VTD-XML军_采用原始的数值类型作为record的类型，q样可以不必用heap。VTD-XML的record机制叫做VTDQVirtual Token DescriptorQ，VTD性能瓉在tokenization阶段px了真的是很y妙很用心的做法。VTD是一?4bits长度的数值类型，记录了每个element的v始位|（offsetQ，长度QlengthQ，深度QdepthQ以及token的类型（typeQ等信息?
注意VTD是固定长度的Q官方决定用64bitsQ，q样做的目的是Z提高性能Q因为长度固定，在读取，查询{操作的时候格外的高效QO(1)Q，也就是可以用数组q种高效的结构来l织VTD大大减少了因为大量用对象而生的性能问题?
VTD的超能力Q一炚w不夸张地_在于它能够XMLq种树Ş的数据结构简单的变换成对一个byte数组的操作，M你能惌到的对于byte数组的操作都可以应用在XML上了。这是因取进来的XML是二q制的（byte数组Q，而VTD则记录了每个element的位|等讉K用信息，当我们找到要操作的VTD的时候，只要用offset与length{信息就可以对原始byte数组q行M操作Q或者可以直接对VTDq行操作。D例来_我想在一个大XML中找Z个elementq删除它Q那么我只需要找到这个element的VTDQ遍历方法稍候再ԌQ将q个VTD从VTD数组中删除，然后再利用所有的VTD写出到另一个byte数组中就可以了，因ؓ删除的VTD标明了要删除的element的位|，所以在新写入的byte数组中就不会出现q段element了，用VTD写入新的byte数组实际上就是一个byte数组的拷贝，其效率相当的高，q就是所谓的增量更新Qincremental updateQ?br />关于VTD-XML的遍历方式，它采用了LC (Location Cache)Q简单地说就是将VTD以其深度作ؓ标准构徏的一个树形的表结构。LC的entry也是64bits长的数值类型，?2bits代表一个VTD的烦引（indexQ，?2bits代表了这个VTD的第一个child的烦引。利用这些信息就可以计算ZQ何一个你惌到达的位|了Q关于具体的遍历Ҏ请参看官方网站的文章。基于这U遍历方式的VTD-XML有与DOM不同的操作接口，q是可以理解的，q且QVTD-XML的这U遍历方式可以在最的几步内将你带C所需要的地方去，遍历的性能十分H出?/p>
ȝ
像你上面看到的QVTD-XML有着qh的特性，而如今的1.5版本中已l加入了XPath的支持（只要可以遍历Q就可以支持XPathQ这是早晚的?-)Q，它的实用性已l超了当今我们所惌的范围了。另一个VTD-XML的超能力Q就是基于它现在的处理方式，完全可以支持来的Binary XML标准Qƈ通过Binary化将XML的应用推向更高一层楼Q这也是我目前所期待的！:-)
不过QVTD-XML仍然有许多需要改q与完善的地方，q方面值得我们努力与探讨?/p>
Z提一下，VTD-XML是开源项目（GPLQ，目前有Java、C两种q_支持。如果你惛_.NET试一试的话徏议你使用IKVMQBSD style licenseQ将VTD-XML转换?NETE序集，怿你会喜欢上它的！;-)
]]>