RE: [xsl] Performance problem

Subject: RE: [xsl] Performance problem
From: "ficfic m" <ficfic@xxxxxxxxxxx>
Date: Thu, 17 Feb 2005 11:09:51 +0200
Hi Michael,

I'd like to thank you and David for your concern.

The Idea of breaking the data up to pieces had occurred to me. But since my xml file is like a database it cant be divided to smaller parts. so I tried using only the xsl and resultant-html to simulate next-prev but didn't succeed. The transformation is done once and I cant apply a script from my resultant-html to get the next records. I know that I can do it using Saxon or writing program in SAXXML (Microsoft), but I cannot use these methods. Do you have any solution to my probelm ?


From: "Michael Kay" <mike@xxxxxxxxxxxx>
Reply-To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: [xsl] Performance problem
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

Express yourself instantly with MSN Messenger! Download today it's FREE!

Current Thread