|
序言
本文所提及的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一样拥有大量对象的时候这个额外开支也是不小的。
引起以上两个问 [1] [2] [3] [4] 下一页
|
