Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > XML > "Don't Search For Instructions Until..." statement?

Reply
Thread Tools

"Don't Search For Instructions Until..." statement?

 
 
VK
Guest
Posts: n/a
 
      05-28-2006
Let's say I have a rather big HTML template like

<?xml version="1.0" encoding="ISO-8859-1"?>
....
<snip>
....
<xsl:template match="/">
<html>
<!-- ...
A lot of HTML but no XSL so far
.... -->
<xsl:for-each select="repository/item">
<!--
Here finally XSL comes into play
-->
</xsl:for-each>
....
</html>
</xsl:template>
</xsl:transform>

If I understand properly, XSL will still study each line after
<xsl:template match="/"> for XSL command wasting its time. Is there a
way to start output (thus use
<xsl:template match="/">) but postpone XSL parsing until some
predefined sequence? Namely I'm thinking of some kind of Perl
equivalent of single-quote print block like
print <<'EOT'
....
EOT

 
Reply With Quote
 
 
 
 
Joe Kesselman
Guest
Posts: n/a
 
      05-29-2006
VK wrote:
> If I understand properly, XSL will still study each line after
> <xsl:template match="/"> for XSL command wasting its time.


I suspect that isn't going to take a significant amount of time, but if
you insist on trying to avoid it -- move some of the literal content out
of the template into a stylesheet variable, and just insert its value.

Alternatively, switch to a compiled stylesheet system such as Xalan's
XSLTC support, which will probably optimize this automagically without
your having to do anything to the stylesheet.
 
Reply With Quote
 
 
 
 
Andy Dingley
Guest
Posts: n/a
 
      05-30-2006

VK wrote:

> If I understand properly, XSL will still study each line after
> <xsl:template match="/"> for XSL command wasting its time.


Yes, it's called "parsing".

In practice, parsing is typically the slowest part of building
server-side web output when loading a new stylesheet each time. So look
at an XSLT transform engine that allows you to cache this after loading
and re-use the same stylesheet next time. It's a useful saving.

 
Reply With Quote
 
Joe Kesselman
Guest
Posts: n/a
 
      05-30-2006
Andy Dingley <(E-Mail Removed)> wrote:
> at an XSLT transform engine that allows you to cache this after loading
> and re-use the same stylesheet next time. It's a useful saving.


Note that the TrAX APIs support this -- you can load a stylesheet once
(which is when stylesheet parsing generally occurs) and then invoke it
multiple times.
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      05-31-2006

Joe Kesselman wrote:
> Andy Dingley <(E-Mail Removed)> wrote:
> > at an XSLT transform engine that allows you to cache this after loading
> > and re-use the same stylesheet next time. It's a useful saving.

>
> Note that the TrAX APIs support this -- you can load a stylesheet once
> (which is when stylesheet parsing generally occurs) and then invoke it
> multiple times.


Thanks to both of you.

Does enclosing non-XSL part of template into <xsl:text>...</xsl:text>
have an effect on parsing (speed)? Would be glad to be pointed to some
specs/test results.

 
Reply With Quote
 
Joe Kesselman
Guest
Posts: n/a
 
      05-31-2006
VK wrote:
> Does enclosing non-XSL part of template into <xsl:text>...</xsl:text>
> have an effect on parsing (speed)?


I wouldn't expect xsl:text to make much difference in stylesheet
parse-and-interpret-or-compile speed.

Note that you can't use xsl:text to escape literal result elements; as
its name implies it's intended to give more explicit control over the
boundaries of character content.

I strongly suspect you're micro-optimizing the wrong part of your
problem. Have you run a performance analysis to find out where your
system is actually spending its time? As with any programming language,
rewriting a stylesheet can sometimes tremendously improve its performance.
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      05-31-2006

Joe Kesselman wrote:
> I wouldn't expect xsl:text to make much difference in stylesheet
> parse-and-interpret-or-compile speed.


ACK - but I'll still check with timers.

> Note that you can't use xsl:text to escape literal result elements; as
> its name implies it's intended to give more explicit control over the
> boundaries of character content.


ACK

> I strongly suspect you're micro-optimizing the wrong part of your
> problem.


Actually I don't have any performance problems right at this moment.
I'm just thinking of some common technics (of they exists) for
optimisation of non-XSL part of templates.

 
Reply With Quote
 
Joe Kesselman
Guest
Posts: n/a
 
      05-31-2006
VK wrote:
> Actually I don't have any performance problems right at this moment.
> I'm just thinking of some common technics (of they exists) for
> optimisation of non-XSL part of templates.


The best ways to optimize those are to do so inside the XSLT processor
(a) compile the stylesheet, and (b) while you're at it, prepare blocks
of literal output so they can be dumped out relatively quickly.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can anyone suggest reasons NOT to follow these instructions? Tom Betz Firefox 11 01-12-2005 03:52 AM
Step By Step Instructions Glenallan Wireless Networking 15 12-29-2004 12:13 AM
search within a search within a search - looking for better way...my script times out Abby Lee ASP General 5 08-02-2004 04:01 PM
Password Recovery on Pix 515E (I have tried the instructions from Cisco...) Anonymous Poster Cisco 4 04-25-2004 01:10 PM



Advertisments