RE: [xsl] Performance problem

Subject: RE: [xsl] Performance problem
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Tue, 15 Feb 2005 17:15:00 -0000
It seems strange to me to display 60K records on a browser page. There's no
way the user is going to look at them all. Break it up into pieces, so the
user gets to see something quickly, and can ask for more if they want it.

You're presumably measuring stop-watch response time, which includes reading
the document, parsing it, transforming it, and rendering the result. I
wouldn't be surprised if rendering accounts for a fair bit of the time. My
guess is that the transformation is probably taking only 15 seconds or so
(which definitely means there's no point looking for 10% improvements). To
test this, try using msxml3 from the command line to do the same
transformation. You might be able to improve the rendering time by changing
the way you generate the HTML - but that's off-topic for this list (and not
something I can help you with).  

> 1. How can I know what XSLT processor I'm using and in which 
> version? (I 
> guess I'm using Microsoft).

As David said, you can use system-property(), but you're using MSXML3.
> 2. From your experience what you can tell about my performance?

See above.

> 3. I think that the "div" (=divide) command in the 
> format-bytes is the heavy 
> thing. does someone have an alternative to my algorithm?

This is very unlikely to be a significant factor.
> 4. Apparently I'm not using xslt2 because I get the following 
> error "Keyword 
> xsl:stylesheet may not contain xsl:function". Where can I 
> find the "built-in 
> date handling functions"? Does it work only with elements and 
> xslt2? should 
> I move to xslt2 ? how can I do it ?

There's currently no client-side XSLT engine that implements XSLT 2. If you
want to use XSLT 2.0, you need to move to a server-side approach.
> 5. Michael, I read somewhere that you said it is better to 
> use <template 
> match=".."> instead of <for-each> what about my case ?

This is an orthogonal question. It's not relevant to performance; it's all
about maintainability and reusability.
> 6. I'll be happy to get any tweaks to make it 10% faster, 

If users aren't happy with the performance then 10% won't buy them over. 

As I said at the beginning of the message, you need to ask yourself why you
are making the user wait 60 seconds while you render a vast amount of data
that he's not likely to look at.

Michael Kay

Current Thread