Java中的XML: 文档模型，第一部分：性能 - 编程入门网
| 的不同之处还在于避免使用 Collections 类。该组合为其提供了非常简单的 API，在许多方面类似于带有附加 XPath 操作的 DOM API 简化版本。
仅当空白与非空白文本内容邻近时，EXML 才在文档中保留空白，这就将 EXML 限制成 XML 文档的一个子集。标准 XML 需要在读取文档时保留该空白，除非对文档 DTD 可以确认有无空白无关紧要。对于事先已经知道空白无关紧要的许多 XML 应用程序来说，EXML 方法工作得很好，但是它防止对于期望保留空白的文档（例如，生成由浏览器显示或查看的文档的应用程序）使用 EXML。 这种空白的删除会对性能比较产生误导效果 ― 许多类型的测试范围与文档中的组件个数成比例，并且由 EXML 删除的每个空白序列都是其它模型中的组件。EXML 包含在本文显示的结果中，但是解释性能差异时请记住这种影响。 EXML 使用集成的解析器依据文本文档构建文档表示。除了通过文本方式外，它不提供从 DOM（或 SAX2）转换或转换成 SAX2（或 DOM）事件流的任何方式。EXML 是由 Mind Electric 在禁止将它嵌入某些类型的应用程序或库的受限许可证下发布的开放源码。用于性能比较的版本是 Electric XML 2.2（jar 文件大小是 0.05MB）。 XML Pull Parser XML Pull Parser (XPP）是最近开发的，它演示了 XML 解析的不同方法。与 EXML 一样，XPP 只能适当支持 XML 文档的子集并且不提供验证的任何支持。它同样具有尺寸小的优势。这种优势再与拉回解析器方法结合，使它成为该比较中的良好替换项。 XPP 几乎独占地使用接口，但是它仅使用所有类中的一小部分。和 EXML 一样，XPP 避免使用 API 中的 Collections 类。总的来说，它是本文中最简单的文档模型 API。 将 XPP 限制成 XML 文档子集的局限性是它不支持文档中的实体、注释或处理指示信息。XPP 创建仅包含元素、属性（包括“名称空间”）和内容文本的文档结构。这对于某些类型的应用程序来说是一种非常严格的限制。但是通常它对性能的影响比 EXML 空白处理对性能的影响小。在本文中我仅使用了一个与 XPP 不兼容的测试文件，并且在带有注释的图表中显示了 XPP 结果，该注释不包含该文件。 XPP 中的拉回解析器支持（本文中称为 XPP 拉回）通过将解析实际上推迟到访问文档的一个组件时才进行，然后按照构造那个组件的需要对文档进行解析。该技术想实现允许非常快速的文档显示或分类应用，尤其在需要转发或除去（而不是对文档进行完全解析和处理）文档时。该方法的使用是可选的，如果以非拉回型方式使用 XPP，它对整个文档进行解析并且同时地构建完整的表示。 与 EXML 一样，XPP 使用依据文本文档构建文档表示的集成语法解析器，并且除了通过文本方式外，它不提供从 DOM（或 SAX2）转换或转换成 SAX2（或 DOM）事件流的任何方式。XPP 是具有 Apache 样式许可证的开放源代码。用于性能比较的版本是 PullParser 2.0.1 Beta 8（jar 文件大小是 0.04MB）。 测试详细信息 所显示的计时结果是来自使用 Sun Microsystems Java version 1.3.1、Java HotSpot Client VM 1.3.1-b24 测试，这些软件是运行在带有 256MB RAM 的 Athlon 1GHz 系统上的 Redhat Linux 7.1 下。将这些测试的初始 JVM 和最大内存大小都设置成 128MB，我想将它表示为服务器类型执行环境。 在使用初始缺省 JVM 内存设置为 2MB 和最大内存为 64MB 运行的测试中，带有较大 jar 文件大小（DOM、JDOM 和 dom4j）的模型的结果非常差，尤其在运行测试的平均时间中。这可能是由于内存受限执行的 HotSpot JVM 的无效操作引起的。 文档模型中的两种（XPP 和 EXML）支持直接将文档输入成“字符串”或字符数组。该类型直接输入不能代表实际应用程序，因此我在这些测试中避免使用它。对于输入和输出，我使用 Ja |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
