Web Development

General discussion


Performance issues with XSLT in .NET

By greg ·
I am building am application with .NET vb and xml / sql as my data layer. my presentation layer is generated via XSLT.

I started out with the application on classic asp and i am seeing considerable performance issues in the xslt rendering with the .NET.

are there any tips for light-weight xslt transforms with .NET? I am willing sacrifice a little functionality for performance increase.

thanks - Greg

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

by johnraz In reply to Performance issues with X ...

Couldn?t help notice the similarity with xml/xsl applications I?ve developed. It?s really a great way to go, but you?ve got to use it wisely such as well designed template matching, avoiding unnecessary node transversal and processing. You might also look into xsltc or other template caching techniques.

Another way to reduce this problem is by the use of dedicated xml processing hardware. You?ll find a great example in the IBM DataPower XA35. It can act as a proxy for your xml/xsl site, offering caching and highly optimized xsl processing.


I work for DataPower and have seen it solve many problems such as this.

Collapse -

by clavius In reply to Performance issues with X ...

Dunno if you've seen this, but if not, MS has an article on the subject:

Also, there are plenty of ways to write an inefficient XSLT stylesheet. In other words, the slowness may have nothing to do with .NET, but rather with the way your stylesheet is structured. For hints on how to optimize it, check out the following links:

Good luck!

Collapse -

by hugh.moran In reply to Performance issues with X ...


I have just read your post about performance concerns.

I want to draw your attention to a new technology we have recently made available in beta.

Persistore is the first managed class library for .NET 2 that provides access to persistent shared memory.

The technology lets you drag a load of files into a repository (a bit like a database) which then immediately become memory resident SharedStream objects; this has implications for XM and XSL processing.

By keeping this data in-memory (actually mapped into the address space, even the web server) one avoids the overhead of going through the NTFS system or to an external database.

SharedStreams may be used anywhere that a stream is used, and the data is actually in memory, so it accessed very rapidly indeed, in C# or VB.NET this is relatively simple code.

I won?t dwell on these details here; you are encouraged to download the beta class library from our website: http://www.morantex.com/Persistore.aspx

Do not hesitate to contact me with questions, feature requests or bugs, we will try to include any suggestions in our next beta.

On a 64-bit system one can in principle, store over 8,000 G bytes of XML and other data in a shared memory repository, this promises improved performance over a more conventional storage medium.


Related Discussions

Related Forums