XSL 流在小文档上的用例，而不是提前退出？

Posted 2023-02-16

【中文标题】XSL 流在小文档上的用例，而不是提前退出？

【英文标题】：Use case for XSL Streaming on a small document other than early exit?

【发布时间】：2014-03-06 16:40:48

【问题描述】：

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

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

我写信是想问一下，在实践中，是否还有第三个真正的用例：

C.您有一个简单的转换并希望放弃构建 XML 树所需的 CPU 时间。 举个例子，假设一家商店的货物存储在一个 XML 结构中，格式如下：

*** = 年份

第二级 = 月

第 3 级 = 发货日

第 4 级 = 货件 ID

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

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

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

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

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

【参考方案1】：

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

我知道有许多领域有优化空间（或至少需要进行详细测量以发现是否有优化空间），但首要任务是让一切正常运行并获得足够多的测试用例可以尝试优化而不会有引入更多错误的风险。

【讨论】：

我可能会偶尔继续尝试这个，如果我最终找到一个真实的案例，我的现实生活中的一个分析最终因放弃树构建而受益，我会告诉你。我的工作实际上通常很少有序列化成本，因为我使用 XSL 来分析数据而不是转换它。 [我宁愿使用原生 XPath3 的语言工作，也不愿将所有内容都转换为 PyTables...]

另一种减少内存需求的情况当然是当您拥有大量小文档而不是单个大文档时。这可能是使用 collection() 的批处理过程，也可能是执行大量转换的高吞吐量 Web 服务。

【参考方案2】：

除了大型文档之外，流式传输的另一个可能优势——取决于样式表和输入文档的确切特征以及您使用输出的方式——可能会减少延迟。也就是说，可以比在更传统的处理模型中更早地开始将文档的开始传送到处理的下一个阶段（或给用户）。例如，如果您正在生成 html，浏览器可能会更快地将页面显示在屏幕上。

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

我不确定 Saxon 的内部结构，但 Xalan 长期以来一直提供一种“增量解析”模式，旨在允许进行同样的权衡；在某些情况下，它可以减少延迟，但会增加一些开销来跟踪到目前为止已解析了多少输入，因此可能会降低吞吐量。

选择对您的应用有意义的模式。任务工具...

（我仍然希望看到有人采用 IBM 获得专利的流式优化投影概念。这是我所见过的识别流式优化机会的最通用方法在不受限制的 XSLT 中。唉，更高优先级的工作消耗了将其从原型转化为生产质量所需的资源，而且我还没有找到个人时间尝试 skunkworks 版本。）

【讨论】：

感谢您的来信。我没有想到这一点，但我对 xslt 的专业使用目前并不关心延迟，只关心实现所有转换所需的总时间。

我想知道为什么浏览器没有推动流式 XSLT 以进行客户端 XSLT 渲染......哦，我忘了，他们正忙于使编写的“现实世界”丑陋的 sphagetti HTML 合法化20 年前。