xml - XSL Streaming 在除提前退出以外的小文档上的用例？

Question

我正在研究在 XSL 中使用流式处理的用例。我知道两个明显的案例:

一个。您需要转换一个非常大的文档，而整个文档无法保存在内存中。B. 你只需要文档的一小部分，而且通常那个“小部分”靠近顶部。然后，您可以通过提前退出来节省时间。

我写信是想问一下，在实践中是否存在第三个真实用例:

C.您有一个简单的转换并且想要放弃构建 XML 树所需的 CPU 时间。举个例子，假设一家商店的 cargo 存储在具有以下格式的 XML 结构中:

顶级 = 年份

第二级 = 月

第 3 级 = 发货日期

第 4 级 = 货件 ID

第 5 级 = 装运中的单个项目

举个例子，考虑一个转换，其目的是在“月”级别提取信息......只需要存储在月元素属性中的数据，而不需要关于这些节点的后代的任何信息.

即使必须读取整个文档，这样的转换是否有可能从流式传输中受益？我希望可以节省一些时间，因为不需要 build 树，但在我有限的测试中，情况似乎并非如此。

我在 SAXON 9.5.1.3 中尝试了这样一个示例，流式传输比非流式示例慢了大约 20%。也许执行流所涉及的开销几乎总是比不构建树所获得的时间更糟糕？ (至少在撒克逊语中，树的构建速度非常快。)

或者我在测试中犯了错误，并且有明显的例子表明流式传输更有效，即使必须读取整个文档也是如此？

Answer 1

感谢您提供有关 Saxon 的数据。我对 20% 的开销并不感到惊讶；如果它是 60%，我不会感到惊讶。这在很大程度上与实现的成熟度有关；在你开始考虑让它变得更快之前，让流媒体工作已经够难的了。但是，如果它在文件小到足以在内存中处理的情况下变得比传统处理快得多，我会感到惊讶。这在一定程度上是因为您可以使用流式处理进行的那种转换的性能很可能受解析和序列化成本的支配，这在两种模型中都是相同的。

我知道许多领域存在优化空间(或者至少进行详细测量以发现是否存在优化空间)，但首要任务是使其全部正常运行并获得足够的测试用例到位，可以在不冒引入更多错误的情况下尝试优化。