目前，只有三个 已知的XSLT 2.0处理器，从速度和内存利用率两方面来看，
Saxon 9.x 可能是最高效的（至少根据我的经验）。 Saxon-
SA （ Saxon的模式识别
版本，由于B（基本）版本不是免费的）具有用于流处理的特殊扩展。
从各种现有的 XSLT 1.0 处理器中，.NET
XslCompiledTransform （基于C＃，而不是Java！）似乎是冠军。
在XSLT 1.0处理器的基于Java的世界中， Saxon 6.x 再次非常出色。
更新 ：
现在，从最初回答这个问题的日期开始已有3年多的时间，没有任何证据表明所提到的XSLT处理器之间的效率差异已经改变。
至于流媒体 ：
- 即使没有任何流，也可以很好地处理带有“数百万个节点”的XML文档 。我进行了一个实验，其中Saxom 9.1.07处理了一个XML文档，其中包含大约一百万个带有整数值的3级元素。转换只是计算它们的总和。我的计算机上进行转换的总时间少于1.5秒。所用的内存为500MB，甚至在10年前PC都可以拥有，
以下是Saxon的参考消息，其中显示了有关转换的详细信息：
Saxon 9.1.0.7J from SaxonicaJava version 1.6.0_17Stylesheet compilation time: 190 millisecondsProcessing file:/C:tempdeleteMRowst.xmlBuilding tree for file:/C:tempdeleteMRowst.xml using classnet.sf.saxon.tinytree.TinyBuilder
Tree built in 1053 milliseconds
Tree size: 3075004 nodes, 1800000 characters, 0 attributes
Loading net.sf.saxon.event.MessageEmitter
Execution time: 1448 milliseconds
Memory used: 506661648
NamePool contents: 14 entries in 14 chains. 6 prefixes, 6 URIs
- 撒克逊9.4有 一个 撒克逊：流（）扩展功能 ，可用于处理巨大的XML文档。
以下是文档摘录 ：
在撒克逊人流中基本上有两种方法：
突发模式流传输：通过这种方法，将大文件的转换分解为文件小片段的转换序列。依次从输入中读取每个片段，将其变成内存中的一棵小树，进行转换，然后写入输出文件。
此方法适用于结构相当平坦的文件，例如包含数百万条日志记录的日志文件，其中每个日志记录的处理均独立于之前的记录。
此技术的一种变体使用新的XSLT 3.0 xsl：iterate指令代替xsl：for-
each遍历记录。这样可以在处理记录时维护工作数据：例如，可以在运行结束时输出总计或平均值，或者根据文件中记录的内容来处理一条记录。
。xsl：iterate指令还允许提早退出循环，这使得转换可以从大文件的开头处理数据，而无需实际读取整个文件。XSLT和XQuery均提供突发模式流传输，但是XQuery中没有与xsl：iterate构造等效的流。
流模板：这种方法遵循传统的XSLT处理模式，该模式通过将模板规则与每个级别的节点匹配来执行输入XML层次结构的递归下降，但是一次这样做一个元素，而无需在内存中构建树。
每个模板都属于一个模式（也许是默认的未命名模式），流式传输是该模式的属性，可以使用新的xsl：mode声明来指定。如果该模式被声明为可流式处理，则该模式下的每个模板规则都必须遵守可流式处理规则。
流处理中允许的规则非常复杂，但是基本原理是给定节点的模板规则只能按顺序读取该节点的后代一次。当前Saxon实现中的限制还带来了其他规则：例如，尽管分组使用从理论上讲与流式实现是一致的，但当前在Saxon中尚未实现。
XSLT 3.0 将具有标准的流功能。但是，W3C文档仍处于“工作草案”状态，并且流式传输规范可能会在后续的草案版本中更改。因此，不存在当前草案（流）规范的实现。
警告 ：并非所有转换都可以在流模式下执行-与XSLT处理器无关。对于大型文档，无法在流模式（RAM数量有限）中无法执行的转换示例之一是对它们的元素进行排序（例如，使用公共属性）。
