Java中的XML: 文档模型，第一部分：性能 - 编程入门网
va 流封装字节以消除 I/O 对性能的影响，而保留了用于 XML 文档输入和输出的应用程序在典型情况下使用的语言接口。
Java中的XML: 文档模型，第一部分：性能(3)时间:2011-01-25 IBM Dennis M. Sosnoski性能比较 本文中使用的性能比较基于对一组选中的 XML 文档进行的解析和使用，这些文档试图代表较大范围的应用程序： much_ado.xml，标记成 XML 的莎士比亚戏剧。没有属性并且是相当简单的结构（202K 字节）。 periodic.xml, XML 中的元素的周期表。一些属性，也是相当简单的（117K 字节）。 soap1.xml，取自规范的样本 SOAP 文档。大量名称空间和属性（0.4K 字节，每次测试需要重复 49 次）。 soap2.xml，SOAP 文档格式中的值列表。大量名称空间和属性（134K 字节）。 nt.xml，标记为 XML 的“新约”。没有属性并且非常简单的结构，大量文本内容（1047K 字节）。 xml.xml，XML 规范，不带 DTD 引用，在内部定义所有实体。带有大量混合内容的文本样式标记，一些属性（160K 字节）。 除了非常小的 soap1.xml 文档之外，所有评测时间都是指文档的每次特定测试所经历的时间。在 soap1.xml 的情况下，评测的时间是 49 个连续的文档测试（总数为 20K 字节文本的足够副本数）。 测试框架在一个文档上运行一个特定的测试多次（这里显示运行了 10 次），依此跟踪该测试的最短时间和平均时间，然后继续同一文档上的下一个测试。完成对一个文档的全部测试序列后，它对下一个文档重复该过程。为防止文档模型之间的交互，在执行每个测试框架时仅测试一个模型。 HotSpot 以及类似于动态优化 JVM 的计时基准程序是出了名的棘手的；测试序列中的小变化经常导致计时结果发生很大变化。我已经发现对于执行特定代码段的平均时间时，确实如此；最短时间比较一致，正是我在这些结果中列出的值。可以参阅第一次测试（文档构建时间）的 平均和最短时间的比较。 文档构建时间 文档构建时间测试检查解析文本文档和构造文档表示所需的时间。出于比较目的，已经在图表中包含了使用 Crimson 和 Xerces SAX2 解析的 SAX2 解析时间，因为大多数文档模型（除了 EXML 和 XPP 外的所有文档）使用 SAX2 解析事件流作为文档构建过程的输入。图 1 描述了测试结果。 图 1. 文档构建时间
Java中的XML: 文档模型，第一部分：性能(4)时间:2011-01-25 IBM Dennis M. Sosnoski对于大多数测试文档来说，XPP 拉回的构建时间太短以至于难以计算（因为在这种情况下，实际上没有对该文档进行解析），只显示为非常短的 soap1.xml。对于该文件，拉回解析器内存大小和相关的创建开销使 XPP 显得相对比较缓慢。这是因为测试程序为正在进行解析的文档的每个副本创建一个新的拉回解析器副本。在 soap1.xml 情况下，每次评测时间使用 49 个副本。分配与初始化这些解析器实例的开销大于重复解析文本并构建文档表示的大多数其它方法所需的时间。 XPP 的作者在一个电子邮件的讨论中指出，在实际应用程序中，可以合用拉回解析器实例以重新使用。如果这样做的话，soap1.xml 文件的开销将明显降到忽略不计程度。对于更大的文件，甚至不需要合用，拉回解析器创建开销也可以变得忽略不计。 在本测试中，XPP（带有完整解析），带有延迟节点创建的 Xerces 和 dom4j 都显示整体上的同等性能。延迟的 Xerces 对于较大的文档尤其出色，但是对于较小的文档的开销较高 ― 甚至比常规 Xerces DOM 高很多。在第一次使用文档的一部分时，延迟节点创建方法的开销也较高，这会降低快速解析的优势。 对于较小的 soap1.xml 文件，所有格式（SAX2 解析、常规 DOM 和延迟 DOM）的 Xerces 的显得开销较高。对于该文件 XPP（完全解析）尤其出色，对于 soap1.xml，EXM |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
