3

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

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

我写信是想问在实践中是否存在第三个真实用例：

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

顶级 = 年份

第二级 = 月

第 3 级 = 发货日

第 4 级 = 货件 ID

第 5 级 = 装运中的单个物品

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

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

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

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

4

2 回答 2

4

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

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

于 2014-02-09T13:46:21.607 回答
3

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

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

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

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

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

于 2014-02-09T17:02:18.093 回答