XSLT の 2 つのバージョンのベンチマークを試みています。現在、.NET コンポーネントから呼び出される xml 変換以降、Visual Studio を使用してデバッグしています。VS 2010 は、私が開発に使用する IDE です。
私が得る唯一の手がかりは、出力ウィンドウからのものです（以下は例です）：
スタイルシートの読み込み時間: 656.2 ミリ秒
スタイルシートの JIT 時間: 11.18 ミリ秒
スタイルシートの実行時間: 177.8 ミリ秒
「スタイルシートの実行時間」に気を配る必要があるだけだと思いますが、これらの値が XSL の実際の機能を反映しているかどうかはわかりません。実行ごとに継続的に変化しているように見えるからです。
XSL をベンチマークする信頼できる方法があるかどうか知りたいです。.NET ランタイムを使用した XSL のベンチマークに関する実践的な経験があれば、役に立ちます。
この質問は、stackoverflow で以前に尋ねられました。元の質問は次のとおりです。XSLT をプロファイリングして最適化するにはどうすればよいですか?
以下は、受け入れられた回答の抜粋です。
どの XSLT エンジンを使用していますか? .NET エンジンと Visual Studio を使用している場合は、非常に便利な Visual Studio に統合された XSLT プロファイラーを使用できます。
その他の優れたプロファイリング ツールは、Altova の XML Spy と Oxygen です。
XSLT を投稿すると、ボトルネックの可能性がある場所を簡単に知ることができます。一般に、「//」、previous::* および following::* などの XPath 式には注意してください。その他のルールとベスト プラクティス:
- の繰り返し使用は避けてください
"//item"。- 同じノードセットを複数回評価しないでください。変数に保存します。
<xsl:number>できれば避けてください。たとえば、position() を使用します。<xsl:key>たとえば、グループ化の問題を解決するために使用します。- テンプレート ルールでは複雑なパターンを避けてください。代わりに、ルール内で使用してください。
preceding[-sibling]またはfollowing[-sibling]軸を使用するときは注意してください。これは多くの場合、パフォーマンスが n 乗のアルゴリズムを示します。- 同じノード セットを複数回並べ替えないでください。必要に応じて、結果ツリーのフラグメントとして保存し、
node-set()拡張機能を使用してアクセスします。#PCDATA単純な要素 のテキスト値を出力するには<xsl:value-of>、 を優先して使用します<xsl:apply-templates>。([ http://www.dpawson.co.uk/xsl/sect4/N9883.html#d15756e150][4]より)
毎回発生するコンパイルプロセスから混合メトリックを取得しないように実行する前に、呼び出すことができる XSLT がコンパイルされていることを確認します。
XslCompiledTransform クラスを使用して、XSLT が実行前にコンパイルされていることを確認できます。それを破棄せず、オブジェクトを再度作成するたびに変換を再利用することが非常に重要です。オブジェクトは再コンパイルされ、ランダムな時間がかかります。
ここに興味深い記事があります: http://www.windowsdevcenter.com/pub/a/dotnet/2003/07/14/xsltperf.htmlと呼ばれる XSLT Performance in .NET
さらに、.Net の XSLT 変換を他の xslt エンジンにベンチマークします。
XSLT を使用した私の経験では、カスタム関数が変換に追加されない限り、非常に高速でした。通常は小規模から中規模のシートで実行されなかったカスタムコードを呼び出すと、特に多くのインポートや関数呼び出しがないため、非常に高速に実行されるはずです。
本当に心配な場合は、MSDN Enterprise Patterns and Practices の優れた記事で、XML および XSLT 変換のパフォーマンスに関するセクションを参照してください。
記事はこちら: http://msdn.microsoft.com/en-us/library/ff649152.aspx
私が話しているセクションはここにあります: http://msdn.microsoft.com/en-us/library/ff647804.aspx
Microsoft は Benchmarking XSLT に投稿しましたが、これは興味深い読み物です。 http://blogs.msdn.com/b/antosha/archive/2006/07/24/xslcompiledtransform-performance-beating-msxml-4-0.aspx
スタイル シートをコードにプリコンパイルする方法もあり、xslt 変換は読み込まれるだけで、まったく解析されません。
これに関する情報は、次の場所にあります: (Using Precompiled XSLT in .NET) http://my-tech-talk.blogspot.co.uk/2009/03/using-precompiled-xslt-in-net.html
私たち (Michael Kay と Debbie Lockett) が最近 XML London で発表した論文をご覧になることをお勧めします。
http://xmllondon.com/2014/xmllondon-2014-proceedings.pdf
これは、XSLT パフォーマンスのベンチマークを行うときに発生するいくつかの落とし穴について説明しています。Github のプロジェクトも参照してください
https://github.com/Saxonica/XT-Speedo
繰り返し可能な結果を得るには、変換を繰り返し実行して平均を取ることが不可欠です。
結論として、将来このスレッドを参照する可能性のある誰かのためのクイック リファレンスとして、これを要約しています。
.NET の場合、ベンチマークを行う最も簡単な方法は、XSLT プロファイラーを使用することです。しかし問題は、Profiling Tools がインストールされた Microsoft Visual Studio Team System でしか利用できないことです。
利用可能なもう 1 つの適切なオプションは、Saxonica のオープン ソース ツールである XT-Speedo です。それを試してみてください。
これとは別に、簡単な評価のために、XSL の複数の変換を実行し、単純な StopWatch Tick を使用して、ほとんどの場合十分な平均を取得できます。