Storing Xslt Files in Application.

I was wondering if there would be any significant performance increases by
loading Xslt Files into the Application Variables if there were a single or
maybe multiple XSLT file(s) that would be used throughout a website. I do
not know if relieving the I/O burden would overcome the memory/hashtable
lookup from storing one or multiple XSLT Files in the Application Object.

[avnrao]

if you have lot of files getting processed by one single xslt, you can store
XSL Processor in the application.
but having many is not recommended.

Av.
<jo*****@driver .net> wrote in message
news:eM******** ******@TK2MSFTN GP11.phx.gbl...

I was wondering if there would be any significant performance increases by
loading Xslt Files into the Application Variables if there were a single or
maybe multiple XSLT file(s) that would be used throughout a website. I do
not know if relieving the I/O burden would overcome the memory/hashtable
lookup from storing one or multiple XSLT Files in the Application Object.

[Hans Kesting]

<jo*****@driver .net> wrote in message news:eM******** ******@TK2MSFTN GP11.phx.gbl...

I was wondering if there would be any significant performance increases by
loading Xslt Files into the Application Variables if there were a single or
maybe multiple XSLT file(s) that would be used throughout a website. I do
not know if relieving the I/O burden would overcome the memory/hashtable
lookup from storing one or multiple XSLT Files in the Application Object.

Maybe the "Cache" object would be a better choice: you
could set a CacheDependency , so the cached item is removed when
the real file is changed (nice feature when developing).

But: there is one problem, specifically with xslt's! when you use
<xsl:include> elements, the processor knows where to look in
the case of a file, but needs some help when the xslt comes from a string.
(you need to supply an XmlResolver)

Hans Kesting

Well, I was hoping to have found somebody that had actually done this. I
guess I will have to find some spare time to do some benchmarking of my own
and compare the results.

"Hans Kesting" <ne***********@ spamgourmet.com > wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..

<jo*****@driver .net> wrote in message
news:eM******** ******@TK2MSFTN GP11.phx.gbl...

I was wondering if there would be any significant performance increases
by
loading Xslt Files into the Application Variables if there were a single
or
maybe multiple XSLT file(s) that would be used throughout a website. I do
not know if relieving the I/O burden would overcome the memory/hashtable
lookup from storing one or multiple XSLT Files in the Application Object.

Maybe the "Cache" object would be a better choice: you
could set a CacheDependency , so the cached item is removed when
the real file is changed (nice feature when developing).

But: there is one problem, specifically with xslt's! when you use
<xsl:include> elements, the processor knows where to look in
the case of a file, but needs some help when the xslt comes from a string.
(you need to supply an XmlResolver)

Hans Kesting

[Steven Cheng[MSFT]]

Hi John,

I've also never try storing XSLT in ApplicationStat e so as to share for the
applicatoins but I think Hans's suggestion on use the ASP.NET's serverside
Cache is reasonable.

#Adding Items to the Cache
http://msdn.microsoft.com/library/en...ngitemstocache
.asp?frame=true

Thanks.
Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

[Steven Cheng[MSFT]]

Hi John,

Have you got any further ideas on this issue? If there're anything else we
can help, please feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx