Fog Creek Software
Discussion Board

XLST Performance

In a recent post, somone stated that you wouldn't use XSLT if you were interested in performance. My experience runs contrary to that. Most tranformations that I produce only take 10-30ms, so even chaining a number together would still be fast.

This is using the MS XML parser. Some basic tests with Java parsers show the same transformations to take 3-5 times longer, but that's still only 150ms at worst.

We're about to move a major web app to have a totally xml-xlst front-end. Does anyone have any specific experience with XSLT being too slow? Perhaps it doesn't scale??

Sunday, July 20, 2003

As a VB shop we found XLST performance a god send. 

I'm sure that, compared to C or even Perl, XLST isn't the fastest option out there.

However, VB really is incredibly slow at this type of thing, so being able to transform using XSLT gave us a real performance boost.

Ged Byrne
Sunday, July 20, 2003

Cool, thanks.
I'm probably just a little paranoid because it was my call to move to an XML-XSLT front-end.

Sunday, July 20, 2003

There's an increasing number of XSLTC software, also. The "C" stands for "compiled", which means the stylesheet is transformed into an intermediate representation which gives you an additional performance gain when the same stylesheet is applied several times on your documents.

In combination with Java, you might want to check out

Johnny Bravo
Sunday, July 20, 2003

Does anyone have any specific experience with XSLT being too slow?

It's the parser you use that matters. Anyway, cache the end result so you don't have to rerun it on every page load

Tom Vu
Sunday, July 20, 2003

XSLT is not slow by itself. XML is slow (compared to binary).
Here is a comparison of XSLT which converts XML into web page, and ASP (VBScript) page doing the same:

As you can see there is practically no difference.
As for the performance of XSLT in Java applications: recently I remember reading a comparison between different operations in binary C and CLR. One of them was XML processing (do not remember what kind of, exactly). It was 5 times slower than using MSXML.
There are entire frameworks based on XSLT, like cocoon:

List of sites using cocoon:

Alexander Chalucov (
Sunday, July 20, 2003

I was just thinking the other day, "I haven't heard anyone mention XLST in a while."

Why is that? Am I just not paying attention, or are people really not talking about this very much these days?

Monday, July 21, 2003

Anything that uses XML/XSLT can be replaced by hand-coded C/C++/Assembler code that uses a compact, easy-to-parse binary format.  And it will definately be faster, probably by a good margin.

However, XML/XSLT tools are already built, are approaching a nice amount of standardization, and tend to provide you with an acceptable set of advantages to counter the cost in performance.

I mean, if you are building a massive site with huge performance implications where you need to get every last bit of performance because you just *can't* throw more hardware at the problem, these sort of things matter.

But $2000 more in hardware is cheap if it saves your programmer a week or more of development or testing time.

I think the whole XML thing isn't heard of as often simply because people are actually using it in all kinds of different ways.  You don't hear too much about microcontrollers in your personal electronics anymore -- they've become part of the way that business is done now.  The same is true of XML.

Flamebait Sr.
Monday, July 21, 2003

Ah, unless that programmer is me, where a week would only run you $500.

Monday, July 21, 2003

The next version of VS.NET will compile XSLT to IL. The speed increase is awesome.

fool for python
Friday, July 25, 2003

*  Recent Topics

*  Fog Creek Home