Performance XSLT性能

我正在为一个有很多XSLT转换的项目工作。 转换必须尽可能快

为了可读性，我写了很多文章，将“业务逻辑”和 “产出”。比如说

<!-- Business Logic -->
 <xsl:variable name="myLocalVar">
      <xsl:value-of select="func:whateverComputation(params)" />
</xsl:variable>

<!-- more buss logic here -->

<!-- Output -->
<xsl:element name="mytag">
    <xsl:value-of select="$myLocalVar" />
</xsl:element>

当然，这可以写在一个紧凑的形式

<xsl:element name="mytag">
      <xsl:value-of select="func:whateverComputation(params)" />
</xsl:element>

第一种形式比第二种形式慢吗？

来自以下部分：

与XSLT性能相关的几点：

xsl:variables

是动态值。这些变量不在缓存中，每次在XSL中引用它们时都会运行。

xsl:variable

的显式类型转换提高了性能。您可以使用

string（）

和

boolean（）

函数进行类型转换

例如：

尽可能使用属性，而不是使用子元素。使用属性而不是元素可以提高性能。当执行XPath匹配时，属性会更快，因为它们是松散类型的。这使得模式的验证更加容易

与属性值匹配时，请使用枚举器属性。使用多个属性名称作为位，并将其值设置为true或false

如何有效使用XSLT的八个技巧：

保持源文档的小型化。如有必要，先拆分文档

在运行之间将XSLT处理器（和Java VM）加载到内存中

如果重复使用同一样式表，请先编译它

如果重复使用同一源文档，请将其保留在内存中

如果重复执行相同的转换，请不要。而是存储结果

保持输出文档小。例如，如果您正在生成HTML，请使用CSS

切勿多次验证同一源文档

将复杂的转换拆分为几个阶段

关于如何编写高效XSLT的八个技巧：

避免重复使用“//项”

不要对同一节点集求值多次；将其保存在变量中

尽量避免使用

。例如，通过使用

position（）

例如，使用

解决分组问题

避免模板规则中的复杂模式。相反，在规则中使用

使用前面[-sibling]或后面[-sibling]轴时要小心。这通常表示具有n平方性能的算法

不要对同一节点集进行多次排序。如有必要，将其保存为结果树片段，并使用

node-set（）

扩展函数访问它

要输出简单的

#PCDATA

元素的文本值，请优先使用

---

在一般情况下，将函数应用程序的结果保存到一个变量不会对性能产生任何显著影响（有些XSLT处理器（如Saxon）使用延迟求值，因此在实际需要变量之前不会对函数求值）

相反如果必须使用相同的参数多次计算函数，则将结果保存在变量中可能会在某些情况下显著提高效率

提高性能的正确方法是：

确定实际瓶颈的概况/措施

只优化最大的瓶颈

如果仍然需要提高性能，请开始新的迭代，转到1。上面

---

引用Donald Knuth的话：“过早优化是万恶之源”——这实际上是一句名言的改写：“通往地狱的路是由善意铺成的。”

游戏开始有点晚了，但我想我应该分享这个链接：。

我们无法回答这个问题。我们甚至不知道您使用的是什么XSLT处理器。唯一确定的方法是自己对其进行基准测试。（另外，将业务逻辑放在模板中似乎根本不明智。）我同意阿维拉的观点。但请注意，xsl:variable声明显示了一个常见错误：将其更改为

。我已经看到，在样式表中应用此更改可以使速度提高3倍，更不用说使代码更加简洁易读了。将复杂转换拆分为多个阶段有什么好处？更好的内存利用率？转换会更快，而且可以在需要的任何地方重用。当你说“重用”时，你是指在处理过程中重用还是指模块化？我有点困惑。您会说“这些变量不在缓存中，并且每次在XSL中引用它们时都会运行”，但也会说“不要对同一个节点集进行多次求值，请将其保存在变量中”。如果我做了

，那不是每次都会重新计算吗？如果使用，那么每次使用变量时都会计算“/node”，但是可能会导致在某些xslt处理器中缓存该值，请参见quot the raven:404。