级别： 中级 Dennis M. Sosnoski (dms@sosnoski.com), Java 和 XML 顾问, Sosnoski Software Solutions, Inc.
2004 年 6 月 15 日 XML 文档的文本基础带来了很多好处，但是不包括传输性能。XML 文档的其他表示与文本相比可能更小或者处理得更快。这篇文章的第 1 部分讨论了 XML 文档其他表示的基础知识。在第 2 部分，Dennis Sosnoski 比较了大量 XML 文档的文本、gzip 和 XBIS 表示的实际大小和处理开销。他最后考察了 XML 的非文本表示逐渐走向标准化的趋势。
本文的
第 1 部分介绍了 XML 的文本和替代表示的一些背景。第 2 部分中我将讨论使用不同表示方法的实际性能权衡。这里的比较并不完善，因为 XML 的表示有很多种不同的选择，包括针对每种文档类型的模式生成的二进制表示。但是长期以来关于替代表示方法的争论多是情绪化的，缺少真正的事实基础，这些性能比较结果至少可以为希望进行性能比较的开发人员提供一个起点。
度量的标准
比较不同表示的文档大小很容易，只需要用各种形式写出同一些数据，然后记录每种情况的字节数。比较处理速度就稍微麻烦一点。为了公正的比较，必须考察把每种表示转化成应用程序可用的形式所需要的开销，以及从应用程序内部数据生成那种表示的开销。但是，任何特定的应用程序都有自己独特的内部数据，但是在大量的应用程序中如何选择才算是公正的呢？
我认为应该使用 XML 文档的解析事件流表示。因为基本上每个使用 XML 的应用程序都在输入端使用解析器读入文档，并且很多都在输出文档中生成等价的解析事件流，这种选择似乎比较公正。我选用 SAX2 解析器模型作为这些测试的基础，因为它是目前应用最广泛的 Java 语言解析器。
测试细节
所有的测试代码都使用 Java 语言编写，只要可能就使用标准 Java 组件。测试代码（可以从 XBIS 站点下载，链接参见
参考资料）首先解析每个测试文档，并把解析生成的事件流保存在内存中。这样在以后基本上不需要什么开销就能回放解析事件流。然后使用保存的解析事件流生成：
- 文本 XML——通过将其作为
javax.xml.transform.Transformer 复制转换的输入，这是我找到的最快的一种方法；
- gzip 压缩的文本——通过把生成的文本链接到
java.util.zip.GZIPOutputStream ；
- 或者 XBIS——通过将其作为
org.xbis.SAXToXBISAdapter 的输入。
我记录下每种表示的大小，然后反过来把生成的输出作为输入来衡量输入处理的开销（只需要解析文本形式，对于 gzip 压缩文本，向解析器链接一个
java.util.zip.GZIPInputStream ，或者将 XBIS 作为
org.xbis.XBISToSAXAdapter 解码程序的输入）。每种情况下，已经生成的输出处理都会生成一个 SAX2 解析事件流，然后对解析事件进行分析，确保原来的文档内容成功地进行一次来回。
本文中的具体时间度量通过对每个或每组文档运行 10 遍（读写各 5 遍）得到，只记录最好的那一遍。不是每一遍完成整个来回，而是首先进行输出生成，然后再测试输出处理，这样可以分别测量执行的事件。不同的表示都单独执行测试程序，以免因为 JVM 的优化造成一组测试对另一组测试产生负面影响。本文中的时间测试在运行 Mandrake Linux 9.1 和 IBM 1.2.1 JVM for Linux 的 Athlon 2000+ 系统上进行。如果用 Sun 1.4.2 JVM 测试，gzip 测试运行的性能要比这里的结果差很多，输出处理要多花大约七倍的时间。除了 gzip 测试时间之外，对于其他测试，这两种 JVM 的结构都差不多。这里的时间是使用 Piccolo SAX2 解析器得到的，因为它是经过测试的 SAX2 解析器中性能最快的。
测试文档
我使用了分解成中型和大型独立文档的测试数据集，以及一些更小文档的集合。中型文档包括：
-
periodic.xml——XML 形式的元素周期表（114K 字节）
-
soap.xml——从一个测试 Web 服务中截获的 SOAP 响应消息（157K 字节）
-
xml.xml——包含实体定义的 XML 推荐标准文本（156K字节）
大型文档包括：
-
weblog.xml——重新格式化为 XML 的 Web 页面访问日志（2.9M 字节）
-
factbook.xml——重新格式化为 XML 的 CIA World Factbook 数据（4.0M 字节）
小型文档集合包括：
-
ants——Ant 构建工具使用的 XML 配置文件（18 个文件，共 100K 字节）
-
fms——来自 Freshmeat.net 的 RDF 文档（37 个文档，共 136K 字节）
-
soaps——示例 SOAP 文档（42 个文档，共 30K 字节）
-
webs——Web 应用程序配置文件（70 个文档，共 132K 字节
看看结果吧
图 1 到图 3 给出了实际的测试结果。总的输出大小以 gzip 最小（文本是 8.0 MB，gzip 是 1.3 MB，XBIS 是 4.1 MB），平均压缩比超过 6:1，但 gzip 的处理时间也是最长的。gzip 格式的处理开销主要在输出端，输入端基本上和普通文本一样快。但是 gzip 的输出时间要比输入时间大得多，gzip 代码总的运行速度大约是文本的三分之一。
图 1. 中型文档的测试结果
对于各种大小和类型的测试文档，XBIS 的性能最好，总体速度比文本快两倍，比 gzip 快六倍。对文本的压缩相对较小，为 2:1，但仍然大大降低了带宽需求。
图 2. 大型文档的测试结果
图 3 中对小型文档集合的测试结果表明，gzip 对较大文档的压缩要比小型文档好得多。每组中的每个文档都使用 gzip 单独压缩，因为文档需要保持独立（多个文档可以使用 XML 在一个流中一起处理，因为文档间没有明确的界限）。图 3 中文档集合的整体大小相对较小，因此 gzip 编码的低效性对整体结果影响不大。
图 3. 小型文档集合的测试结果
使用 gzip 的 XML 感知版本有可能改善 gzip 的时间测量结果。这样就不需要在 gzip 的输入和输出中都经过一个额外的步骤（XML 文本）。gzip 的 XML 感知版本也可以结合其他技术如 XMill（请参阅
参考资料）的思想。尽管 gzip 不大可能赶上 XBIS 的速度。
XBIS 的优点
XBIS 能获得较好的处理速度是因为它具有文本 XML 处理所没有的几种不同的优点。一个优点是消除了 XML 文本的很多冗余。减少冗余可以使表示更短，也是它处理起来更快（特别是对于输入）。另一个优点是和文本 XML 解析器支持的多种不同编码相反，只使用一种方法编码字符数据。因为只需要一种编码，对编码和解码字符序列的处理可以直接建立在 XBIS 处理中，从而不需要一个单独的处理层次。最后，XBIS 不需要逐个字符地检查多种状态变化类型，而这对于文本 XML 是必需的。
在讨论中，一些开发人员提出 XBIS 取得速度上的优势是因为没有执行 XML 处理程序如解析器所需要的结构良好性检查。从某种意义上说，是有意这样设计的，在处理文档的 XBIS 表示时这类结构良好性检查多数都不需要，因为这种格式的编码不可能有多种类型的结构良好性错误。其他类型的错误可能是因为向 XBIS 编码程序提供不当的输入造成的（如元素名或属性名中的非法字符），但是检查这类错误不需要多大的开销。比如对于元素名和属性名，名称只有一次作为文本写入文档的编码形式，当再次使用时将使用一个整数值引用。因此在第一次使用时检查名称是否包含非法字符非常简单。同样的原理也适用于 XBIS 其他类型的结构良好性检查。
前景
在第 1 部分已经提到，对 XML 数据替代表示的兴趣是一个越来越热门的话题。甚至已经成立一个新的 W3C 工作组（XML Binary Characterization Working Group），针对文本 XML 一些替代表示的标准化研究用例、准备测定的方法和可能的开发章程。
这些标准将采用何种形式目前还言之过早。XBIS 式的方法保留了 XML 文档的完整意义（尽管不是所有的语法）具有某些很好的优势，但是基于模式的二进制编码（请参阅第 1 部分“
的数据至上”一节）可以提供某种更紧凑的表示，并可能具有更快的输入输出速度。这类方法之所以可能比 XBIS 更快，是因为可以跳过二进制值和文本的转换。
属于这两种类型的项目正在与 Abstract Syntax Notation One（抽象语言符号，ASN.1）结合进行。这是用于消息抽象描述的语言，可能使用各种不同的规则集编码（包括到二进制编码的转换规则）。ASN.1 已经在电信行业和相关领域得到广泛应用，最近为了处理 XML 进行了调整。一个称为 Fast Infoset 的项目保留了 XML 文档的完整含义（至少大部分含义）。另一个项目 Fast Schema（或者 X.694）直接把数据写成一种编码形式，从模式生成文档的编码和解码规则。目前为止关于 ASN.1 的研究还没有多少公开的可证实的信息，但将来很可能会改变。
现有的方法（包括经过公开讨论的 ASN.1 实现）看起来都没有真正充分利用基于模式的二进制编码的潜能，因为它们在数据对象和实际的编码形式之间都要经过一个转换层。使用类增强技术（如我的 JiBX 数据绑定框架中实现的那些技术，请参阅
参考资料）改进这种方法是可能的。JiBX 提供了非常高的性能，部分原因是使用直接嵌入在类文件中的实现对象和 XML 转换的代码。将同样的方法应用于二进制编码，可以使类有效地把自身序列化为编码或者从编码转换为类。我估计对于等价的数据，这种实现至少要比 XBIS 快几倍。
使用基于模式的二进制编码必然会损失与文本 XML 的兼容性，这样的性能改进还值得吗？它涉及到很多棘手的问题。比方说，从模式生成二进制编码这种方法的讨论常常涉及到 Web 服务。但是，在将来的 Web 服务中，安全性可能具有更重要的地位，二进制编码一般会破坏 XML Canonicalization 原则，而这是该领域多数标准的基础。保留 XML 文档完整含义的 XBIS 式的方法性能可能差一些，但
确实能够与 Canonicalization 及其他标准很好地协作。因此，很可能这两种类型的方法将结合使用。
结束语
测试结果表明，对 XML 使用文本之外的表示，无论从数据大小还是处理开销上看都可以获得明显的好处。标准文本压缩技术可以极大减少文档的大小，代价是额外的处理开销。特定 XML 编码如 XBIS 可以显著降低处理的开销，并适当压缩文档大小。对于只交换已知类型文档的情况，针对特定文档结构量身定做的基于模式的编码在将来有可能提供更好的性能。
不幸的是，可以减少处理开销的编码还没有标准化。一旦标准化，需要减少 XML 处理开销的应用程序就可以独立了（假设存在这样的应用程序，很多专家认为情况并非如此）。现在，任何这类应用程序都可以选择目前正在开发的一种编码，或者生成自己的数据直接编码，完全避开 XML。无论哪种办法都不很令人满意，因此当面临这种选择时，您可以向从事这一领域的某个工作组提出您的观点（比如 W3C 的 XML Binary Characterization Working Group，请参阅
参考资料）。
下载 | 名字 | 大小 | 下载方法 |
|---|
| x-trans2fullxbis.zip | 2815KB | HTTP |
参考资料
关于作者  | 
| | Dennis Sosnoski（dms@sosnoski.com）是位于西雅图地区的 Java 咨询公司 Sosnoski Software Solutions, Inc. 的创始人和首席顾问，XML 和 Web 服务培训和咨询专家。Dennis 有 30 多年的专业软件开发经验，最近几年致力于研究服务器端 XML 和 Java 技术。
|
对本文的评价
| 
