3

残念ながら、私はすべてに XSL を使用する Web サイトに取り組んでいます。パフォーマンスは悲惨です。JITに費やされる時間は約30%です!

私はいつも、この会社が小さなサイトを実行するのに 4 台のサーバーが必要であるという事実は XSL にかかっていると述べていますが、最終的に適切なパフォーマンス レビューを行っています。これは、元のプログラマー (JavaScript 担当者) がXslCompiledTransform型を誤用したことです。

問題は、この API を自分でうまく使用できないことです。このクラスは、コンパイル キャッシュが含まれる .NET 2.0 用に更新されました。私は一日中、キャッシングがどのような状況で機能するかを調べようとしました。元々、コードXslCompiledTransformは変換ごとに新しくなりましたが、これは正しくないように見えましたが、静的にすることも役に立ちません。パフォーマンス プロファイリングでは改善が見られません。

さらに、デバッガーの出力ペインでLoaded 'System.Xml.Xsl.CompiledQuery.5'、同じスタイルシートのポップアップが表示されるので、毎回コンパイルして再度ロードしているように見えます。

キャッシングを行うべきなのかもしれない、つまりXslCompiledTransform、プリロードまたは遅延ロードされたスタイルシートごとにこれらのインスタンスの 1 つをストアに保持する必要があるのではないかと突然思いつきました。

これは正しいですか??Loadスタイルシートごとに1 つのインスタンスを保持して何度も呼び出すのは正しくありませんか?

4

2 に答える 2

0

ac# dev id として、xslt には saxon のルートを使用することをお勧めします。

http://saxon.sourceforge.net/

古い場合は xpath の ms 実装。また、それほど高速ではありません。

于 2013-09-04T16:35:22.470 に答える