从性能角度讲，有两类处理XML文档的方法。批量处理方式需要较短的时间，解析成组的文档。实时方式就是实时的处理文档。批处理方式的性能可以通过在1定时间内处理多少文档来丈量，而实时模式的性能也采取类似的丈量方式，不过是以处理1个文档需要多长时间来计算的。

Scenarios场景

想象1下，你有1个实时工作的系统，比如1个Web服务器。这个系统需要实时的接收客户发来的定单，并需要立即对这个定单进行响应。

这个系统明显不能用批量处理的方式进行。简单的估计1下，假定这是个很简单的定单，只有10个项目，这样所天生的XML文档就比较小，大概每个文档是4KB。这类情况下，使用DOM来解析收到文档。

假设你的定单每小时只有几个，那末系统性能对你来讲还不是题目。但是长远考虑，总有1天定单的数目会多到令你意想到系统性能必须进步。

现在你开始考虑进步性能来适应增长的负荷。你的定单文档已很小了，把它们合并成较大的文档也没有甚么实际的意义。从纵向考虑，这时候候你可以进步现有系统处理能力；从横向考虑，你可以增加更多的系统将负荷分散开。

再看看另1个完全不同的领域，你现在要处理的是1个大型的数据仓库。和Web服务器完全不同，你现在用FTP来传输均匀大小为300MB的XML文档。假设还是使用DOM来解析XML文档，你很快就会碰到***烦。相反，假设你使用SAX就会好的多，它可以直接解析流进的XML文档，而没必要把它们事前都装进内存。

改变文档尺寸
有时候你会碰到特殊情况需要改变XML文档大小。想象1下，和刚才1样你有1个实时处理XML文档的Web服务器，而此时所有的文档大小都是400MB而不是4KB，你不能使用DOM方式，由于那太占内存了。可是由于这是个实时系统，性能很重要。你可使用SAX，不过需要时间答应并要有强大的处理器。

在这类情况下，你可以通过改变文档大小来改进系统履行性能。比如你可以将1个400MB的文档分成10个40MB的，或40个10MB的小文档，这比起处理1个400MB的文档更有效率。这样你便可以够使用DOM方式把文件读进内存进行处理，及时响应每个文档的要求了。同时还可以清除掉不相干的文档。

在批量处理方式上也有类似情况。想象1下你在通过DOM的批处理方式处理数千个4KB大小的文档。最好的方式是将1千个文件合并成1个4MB的文件。由于每个文档的载进都需要占用系统时间（不论是DOM还是SAX）。通过将1千个文档合并成1个，你只需要载进1个文档，占用的时间只是原来的千分之1。