我有一个 XSLT，我正在通过该xdmp:invoke()函数执行，并且我遇到了很长的处理时间才能看到任何结果（在某些情况下，在达到 3600 秒的最大时间后完全超时）。这个 XSLT 在 Oxygen 编辑器中运行大约需要 5 秒。我认为可能会影响性能的一些领域：
xsl:result-document. MarkLogic XSLT 处理器将这些作为结果 XML 节点输出，因为它无法将这些文档物理地保存到文件系统中。 我已经对 XSLT 进行了一些分析，似乎构建变量似乎是执行过程中最耗时的部分。我想知道为什么会这样，为什么它在撒克逊处理器上运行得更快？
非常感谢任何见解。
我的理解是，与文件系统相比，有些 XSLT 性能优化很难或不可能在数据库上下文中实现。此外，Saxon 是 XSLT 的行业领导者，并且比市场上几乎任何产品都快得多，尽管这可能无法解释您所描述的巨大差异。
您没有说您正在运行哪个版本的 MarkLogic，但 8.0 版在 XSLT 性能方面取得了显着的改进。我运行的一些简单测试表明速度提高了 3-4 倍，具体取决于 XSLT。
在 Windows 上运行 MarkLogic 时，我遇到了一些罕见但严重的 XSLT 性能边缘案例。Linux 和 OSX 版本似乎没有这个问题。当 XSLT 任务在多个线程上运行时，它也更加明显。
但是，可以将数据直接保存到文件系统而不是使用xdmp:save.
除非您的 XSLT 涉及非常复杂的模板规则，否则我建议至少在 XQuery 中测试一些对性能敏感的 XSLT 逻辑。可以移植最慢的部分并将这些查询的结果传递给 XSLT。这并不理想，但您可能能够在不重写 XSLT 的情况下获得可接受的性能。
另一个想法，如果问题只是在多通道 XSLT 中构造变量，则将 XSLT 分解为多个 XSLT 并xdmp:xslt-invoke从 XQuery 进行多次调用。但是，我知道xdmp:xslt-invoke拨打电话有一些开销，因此可能是洗牌，或者可能更糟。
我在 ML 7 中遇到了与样式表类似的性能问题。想一想，我有与您提到的样式表相似的样式表，即保存节点序列的变量。似乎 xslt 不可能像 xquery 那样优化。如果您对样式表的性能不满意，我建议您将 xslt 转换为等效的 xquery。我这样做并获得了大约 1~1.5 秒的性能提升。这可能是值得的：）
就我而言，似乎fn:not()在模板匹配规则中使用该函数会导致性能下降。也许如果其他人遇到同样的问题，这可能是一个很好的起点。