在早期退出之外的小文档上进行XSL流处理的用例？

Question

我正在研究在XSL中使用流式传输的用例。我知道两种明确的情况：

答：您需要转换一个非常大的文档，其整个内容不能保存在内存中。 B.您只需要文档的一小部分，并且通常“小部分”靠近顶部。然后，您可以通过提前退出节省时间。

我写信问，如果在实践中，存在第三实际使用案例：

C.你有一个简单的转换，想放弃构建XML树所需的CPU时间。 举个例子，假设一个商店的出货量都存储在以下格式的XML结构：

顶级=年

2级=月

3级=日装运

的在装运

4级=货物ID

5级=个别项目

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

即使必须阅读整个文档，这种转换是否有可能从流式传输中受益？我希望有一段时间可以获得，因为不需要建造树木，但是在我有限的测试中，似乎并非如此。

我在SAXON 9.5.1.3中试过这样一个例子，流式传输比非流式传输例子慢了20％左右。 也许执行流式处理所涉及的开销几乎总是会比没有构建树的时候更糟？ （至少在SAXON，树木建设速度非常快）

或者我在测试中犯了一个错误，并且有清晰的例子说明流式更有效率，即使整个文档都要被读取？

Answer 1

感谢有关撒克逊的数据。我对20％的开销并不感到惊讶。如果是60％，我不会感到惊讶。这很大程度上与实施的成熟度有关;在开始思考如何快速开始之前，完全可以实现流媒体工作。但是，如果在文档小到可以在内存中处理的情况下它比传统处理快得多，我会感到惊讶。这部分是因为您可以使用流式传输进行的这类转换的性能可能会受到解析和序列化成本的影响，这在任一模型中都是相同的。

我知道有很多领域有优化的空间（或者至少对于详细的测量来发现是否有优化的空间），但优先考虑的是让所有的工作都能够正常运行并获得足够的测试机构可以尝试优化案例，而不会引入更多的错误。

Answer 2

除了大文件，其他可能流的优势 - 取决于样式表和输入文档的确切特性以及您如何使用输出 - 可能会减少延迟。也就是说，有可能比传统的处理模型更快地开始将文档的开始传送到下一个处理阶段（或对用户）。例如，如果您正在生成HTML，浏览器可能能够更快地将页面移动到屏幕上。

这可能是一个优势，在某些情况下，即使吞吐量（时间来完成处理文档）有所降低。

我不知道关于Saxon的内部，但Xalan的长期提供其目的是使同一种折衷的“增量分析”模式;它可以在某些情况下减少延迟，但增加了一些开销，用于跟踪迄今为止已解析了多少输入，因此可能会降低吞吐量。

挑选一个有意义的应用程序的模式。工具任务...

（我会仍然喜欢看到有人拿起了IBM专利的流式优化投影概念，这是我认识到的最流行的方法，在不受限制的XSLT优化机会。可惜的是，高优先级的工作里抽出，使之从原型到生产质量所需的资源，而我还没有发现个人时间来尝试科研重地版本）。