XPath では、必要なインスタンスの数を明示的に指定すると、パフォーマンスを改善させることができます。
以下に例を示します。
- /element[1] はエレメントの最初の出現を検出した後、停止します
- /element[2] はエレメントの 2 回目の出現を検出した後、停止します
- /element はメッセージ内のすべてのインスタンスからなるノード・セットを戻し、メッセージ全体の構文解析が行われます
XML コードの最適化のために使用できる手法については、Top 10 tips for using XPath の情報を参照してください。
XSLT にはコードを再使用できるという利点があり、WebSphere® Message
Broker ではロードされたスタイル・シートに対してキャッシングを使用できます。
ただしスタイル・シートは入力として BLOB を必要とし、出力として BLOB を生成します。メッセージ・ツリーとの対話の点では ESQL や Java™ よりも非効率的です。
他の WebSphere Message
Broker テクノロジーと共にストリームの中間でこれが使用された場合、結果としてメッセージの構文解析と直列化が増えます。
XSLT コードのパフォーマンスを最適化するには、テンプレート・オブジェクトを使用できます。こうして変換ごとに異なる変換プログラムを使用し、同じスタイル・シート指示セットによって複数の変換を行います。
また、以下の手法を使ってスタイル・シートの効率を改善させることもできます。
- ノード・セットを取得する効率的な方法として、xsl:key エレメントと key() 関数を使用します
- 可能であれば、xsl:if ステートメントまたは xsl:when ステートメントの代わりにパターン・マッチングを使用します
- 大きなドキュメントのルート付近で "//" (子孫軸) パターンを使用することを避けます
さらに、以下の点も考慮してください。
- 変数を作成するときには、通常、<xsl:variable name="abcElem" select="abc"/> のほうが <xsl:variable name="abcElem"><xsl:value-of-select="abc"/></xsl:variable> よりも高速である
- xsl:for-each はパターン・マッチングを必要としないため、高速である
- xsl:sort は増分的な処理を防ぐ
- マッチ・パターン内で索引述部を使用すると、パフォーマンス上のコストが大きくなる可能性がある
- デコードとエンコードにより、パフォーマンス上のコストが増える
- XSLT をキャッシュした場合、XSLT の使用のたびに構文解析されなくなるため、パフォーマンスが改善される (詳しくは、XSLTransform ノードを参照)